Nach den bisherigen Artikeln zur Konfiguration eines Nagios Servers soll es heute um das Thema SNMP gehen.
SNMP (Simple Network Management Protocol) ist ein modulares Netzwerkprotokoll was sich durch seine Einfachheit und Modularität für die Verwaltung und auch Steuerung verschiedenster Geräte z.B. Router, Switche, etc. im Netzwerk eignet.

SNMP bietet den Vorteil, das Informationen anhand des OID (Object Identifier) abgefragt und zurückgemeldet werden.
Die SNMP Struktur ist mit OIDs wie ein Baum aufgebaut. Wir werden uns in diesem Artikel den Pfad anschauen, in dem Unternehmen ihren eigene Struktur durch die IANA zugewiesen bekommen haben.

Innerhalb der Struktur iso(1).org(3).dod(6).internet(1).private(4).enterprises(1) hat z.B. Cisco die 9 zugeordnet.
Damit befindet sich der “private” Bereich von Cisco unterhalb von .1.3.6.1.4.1.9.

Ein weiterer wichtiger Bereich der uns heute interessiert ist iso(1).org(3).dod(6).internet(1).mgmt(2).MIB-2(1)
unter dem z.B. mit der OID 1.3.6.1.2.1.1.3.0 die Uptime von vielen Geräte abgerufen werden kann.

Einige Statusinformationen wie z.B. die Uptime lassen sich in Nagios normal als Service abfragen.

/etc/nagios/conf.d/services.cfg
define service {
host_name SDXX001,SDXX002,Router001
service_description SNMP Server Uptime
check_command check_snmp_comm!'.1.3.6.1.2.1.1.3.0'!'radium-networks.com'!'360000:'!'720000:'
use InfraCritDev
servicegroups InfraCheck
}

/etc/nagios/conf.d/check_commands.cfg
define command {
command_name check_snmp_comm
command_line $USER1$/check_snmp -H $HOSTADDRESS$ -o $ARG1$ -C $ARG2$ -c $ARG3$ -w $ARG4$
}

Jedoch spielt SNMP besonders mit den Traps seine Vorteile im Monitoring aus, da dadurch nicht alle Informationen aktiv im Netzwerk bei X Geräten abgefragt werden müssen, sondern die Geräte wichtige Informationen selbst als Trap zum Monitoring System melden. Dieses Vorgehen spart natürlich auch Rechenleistung und Bandbreite für die Überwachung.

Weiterlesen

Der Urlaub ist vorbei und die letzten Wochen und das Lernen haben sich gelohnt, die 642-902 (Implementing Cisco IP Routing) Prüfung ist bestanden. Diese Prüfung hat es an vielen Stellen schon in sich. Da hilft es nur vorher zu testen, testen, testen.

Insofern werde ich bei den nächsten Netzwerk Artikeln und auch nachträglich bei bestehenden Artikeln mit auf Videobeiträge setzen um die Thematik noch besser darzustellen.

In diesem Artikel schauen wir uns die BGP Attribute etwas genauer an.

BGP hat viele Regeln zur Routingentscheidung welche auf verschiedene Attribute basieren.
In der folgenden Auflistung sind nur die ersten 8 Prüfungen aufgeführt nach denen BGP die Route wählt.
Sobald eine Prüfung eine Entscheidung herbeiführt, ist die Route gewählt, wodurch weitere Prüfungen nicht mehr durchgeführt werden müssen.

1. Routen mit einem nicht erreichbarem “Next Hop” werden verworfen.
2. Bevorzuge die Route mit dem höchsten “Weight” (nur lokal für den Router und Cisco proprietär)
3. Bevorzuge die Route mit dem höchsten “Local_Pref” Wert (gültig innerhalb des AS)
4. Bevorzuge eine Route die mittels des “Network” Befehls konfiguriert wurde.
5. Bevorzuge eine Route mit dem kürzesten AS_PATH
6. Bevorzuge eine Route mit dem geringsten Ursprungstyp (i (igp) ist bevorzugt vor e (egp) ist bevorzugt vor ? (externen weitergegebenen Routen))
7. Bevorzuge eine Route mit der geringsten Metric ((Multi Exit Discriminator) (med))
8. Bevorzuge eBGP vor iBGP Routen
9. …

Weitere Prüfungen sind immer abstrakter und eventuell auch von einem zufälligen Ergebnis abhängig.

Die von BGP genutzten Attribute lassen sich in verschiedene Klassen aufteilen:

Allgemein bekannte und verpflichtende Attribute (well-known; mandatory) (Herstellerübergreifend und immer verwendet)

• Autonomous System Path
• Next Hop Address
• Origin

Allgemein bekannte und verfügbare Attribute (well-known; discretionary) (Herstellerübergreifend aber nicht zwangsweise verwendet)

• Local Preference
• Atomic Aggregate

Optionale und transitive Attribute (optional; transitive)

Optionale und nicht-transitive Attribute (optional; non-transitive)

• Weight
• Aggregator
• Multi Exit Discriminator (Med/Metric)

Im folgenden Szenario werden die wichtigsten Attribute für das Routing anschauen.

Weiterlesen

In diesem Artikel soll es um NBMA (Non-Broadcast Multiple Access) Netzwerke (hier Frame-Relay) und OSPF gehen. OSPF bietet uns dafür 5 verschiedene Modi die je nach Topologie passend sind.

Eine Frame-Relay Topologie kann in 3 verschiedene Bereiche eingeteilt werden

• Hub and Spoke
• Partial Mesh
• Full Mesh

Die 5 verwendeten Modi sind:

Non Broadcast Mode (RFC)

• Standardmodus für X.25, Frame-Relay, ATM
• Statische Nachbarschaftskonfiguration
• Ein einziges Subnet
• verhält sich wie ein Ethernet Netzwerk
• DR / BDR werden im Segment gewählt

Point-to-Multipoint Mode (RFC)

• Ein einziges Subnet
• Es erfolgt keine DR/BDR Wahl im Netzwerk
• Nachbarschaften werden dynamisch aufgebaut

Point-to-Point Mode (Cisco)

• dedizierte Subinterfaces
• verschiedene Netzwerke
• Es erfolgt keine DR/BDR Wahl im Netzwerk
• Nachbarschaften werden dynamisch aufgebaut

Broadcast (Cisco)

• verhält sich wie ein Ethernet Netzwerk

Point to Multipoint NBMA (Cisco)

• Ein einziges Subnet
• Es erfolgt keine DR/BDR Wahl im Netzwerk
• Statische Nachbarschaftskonfiguration

Innerhalb des folgenden Szenarios werden wir ein OSPF Netzwerk konfigurieren und uns dabei die Modi Point-to-Multipoint, Point-to-Point und den Non Broadcast Mode anschauen.

Weiter zum Szenario

In diesem Artikel möchte ich erneut auf EIGRP eingehen. Insbesondere beim Einsatz in Frame-Relay Netzwerken gibt es ein paar Eigenheiten die zu beachten sind.
Auch wenn es nicht die empfehlenswerte Variante ist, werden wir uns in diesem Szenario eine Hub-and-Spoke Multipoint Konfiguration anschauen.
Innerhalb des Szenarios sind die Router R1 und R4 im Backend angeschlossen und bilden eine Kommunikationsbasis für die Aussenstandorte mit den Routern R2, R3 und R5. Durch die gewählte Topologie wird gewährleistet. dass das Backend selbst bei Ausfall eines Edge Routers noch eine Verbindung zu den Aussenstandorten aufrecht erhält.

Weiterlesen

In den letzten Artikel haben wir mit OSPF, EIGRP uns Routingprotokolle angesehen die innerhalb eines Firmennetzwerks eingesetzt werden. Hierbei handelte es sich um IGP’s (Interior Gateway Protocols). In dem aktuellen Artikel möchte ich auf das BGP (Border Gateway Protocol) eingehen welches als EGP Exterior Gateway Protokoll das Routing im Internet ermöglicht.

BGP Eigenheiten:

• BGP nutzt IP/TCP Port 179 und braucht sich dank TCP nicht selbst darum kümmern dass die gesendeten Pakete auch ankommen.
• Es gibt nur getriggerte Updates
• BGP hat eine sehr langsame Konvergenzgeschwindigkeit
• BGP arbeitet mit teilweise sehr hohen Metric Angaben und bedient sich vieler Attribute um das Routing auf die jeweiligen Bedürfnisse zu tunen
• BGP ist ein Pfadvektorprotokoll und arbeitet ähnlich einem Distanzvektorprotokoll wie RIP aber hat eine Interne Logik um Routingschleifen auszuschließen.
• Ohne “Tuning” operiert es analog zu RIP mittels Hop-Count wobei jede gezählte Station (Hop) ein AS (Autonomous System) ist.
• Die Nachbarschaften (Neighbors) werden manuell konfiguriert
• BGP Neighbors müssen nicht über direkt verbunden sein
• BGP arbeitet innerhalb abgeschlossenen/eigenständigen Systemen (AS Autonomous Systems)

Pakete:

• Open: Öffnet die Session zu einem Nachbarrouter.
• Keepalive: Beantwortet die erhaltene Open Message und wird in regelmäßigen Abständen verschickt um die Verbindung aktiv zu halten.
• Notification: Beendet die Session mit einem Fehler- bzw Statuscode.
• Update: Enthält Änderungen zu erreichbaren Netzwerken

Tabellen:

• Neighbor Tabelle: enthält Informationen zu den konfigurierten Nachbarn
• BGP Tabelle: enthält alle bekannten BGP Routen
• Routing Tabelle: enthält die besten/präferierten Routen zu den Zielnetzwerken

Das erwähnte AS unterscheidet sich von EIGRP da es sich um eine von der IANA vergebene Nummer handelt. Die bisher verwendeten 16bit AS Nummern 1 bis 54271 werden als öffentlich im Internet routbar vergeben und der Bereich 64512 bis 65534 ist für die private Nutzung gedacht. Eine öffentliche ASNummer wird benötigt wenn das Netzwerk einer Organisation über mehrere AS (z.B. redundant über mehrere ISPs) an das Internet angeschlossen ist.

Bei der Nutzung von BGP wird zwischen eBGP (external) und iBGP (internal) unterschieden. eBGP kommt zwischen den BGP Routern zwischen verschiedenen AS zum Einsatz und iBGP wird verwendet um intern innerhalb des AS mit BGP zu arbeiten. Hier gibt es teilweise Besonderheiten zu beachten die auch im folgenden Szenario untersucht werden.

Weiterlesen

IPv6 ist die neue Version des Internet Protokolls das derzeit noch überwiegend in der Version 4 IPv4 genutzt wird.  Neben des größeren Adressraumes (IPv4 32bit; IPv6 128bit) hat das Protokoll aber auch viele Neuerungen die eine Einführung sinnvoll machen. Obwohl IPv6 viele Vorzüge hat und seit 1998 in Form offizieller RFCs existiert, ist IPv4 auch 2011 trotzdem noch das führende Protokoll.

Zu den Anfangszeiten von IPv4 wurde der Adressbereich noch auf Firmen unterteilt, da der massive Erfolg des Internets noch nicht gesehen wurde. Das Ergebnis sind nun ineffektive Routen und nicht genutzte Adressblöcke. Auch dieses wurde bei IPv6 beachtet. IPv6 macht ein einfacheres Routing möglich da primär eine geographische Vergabe von Adressbereichen erfolgt und bisher nur ein kleiner Teil der trotzdem im Vergleich zu IPv4 gigantisch ist auch vergeben wird. Der größte Teil von IPv6 ist laut der Planung noch nicht freigegeben.

Weitere Vorzüge von IPv6 sind z.B. die Implementierung von IPSec (Authentifizierung und Verschlüsselung auf Layer 3), modulare Paketheader (so muss ein Router nur das bearbeiten was für ihn wichtig ist), Autokonfiguration (Stateless Address Autoconfiguration), …

Eine neue Technologie zu haben und die Vorzüge zu sehen ist zwar schön aber bringt noch keine sofortige Umstrukturierungen mit sich. Erst wenn die neuen Technologien genutzt werden erfolgen meist die Implementierungen.  z.B.

• Windows 7 und IPv6 (Verwendung dualer Stapel um IPv4 und IPv6 parallel zu nutzen)
• DirectAccess erfordert IPv6

Schreibweise

Die IPv6 Notation ist in Hexadecimal und wird in 8 Gruppen aufgeteilt.

2001:0000:0000:0000:0000:0032:0FED:1234

Zum Glück können wir das ganze anhand von 2 Regeln kürzen.

1. Führende Nullen im Block müssen nicht geschrieben werden.
   2001:0:0:0:0:32:FED:1234
2. An einer Stelle kann eine Folge von Blöcke mit einem Nullwert durch einen doppelten Doppelpunkt ersetzt werden.
   2001::32:FED:1234

Adresstypen und Addressbereiche:

Adresstypen

• Unicast Adressen 1:1
• Multicast Adressen 1:n
• Anycast Adressen 1:n (der am nächsten benachbarte Host antwortet)

Adressbereiche

• Loopbackadresse ::1/128
• Globale Unicastadresse 2000::/3 (also alle Adressen von 2000:… bis 3FFFF:…)    analog zur öffentliche IPv4 Adresse (Internet)
• Verbindungslokale Adresse FE80::/10 (FE80… bis FEBF…)    analog zur IPv4 APIPA Adresse (Layer 2 ohne Routing)
• unique lokale Unicastadresse FC00::/7 (FC… und FD…)    wie private IPv4 Adresse (Organisation Network)
• Multicastadressen FF00::/8 (FF…)
  zb.
  FF02::1:2 DHCPv6 relay agents and servers
  FF05::1:3 DHCPv6 Servers
  FF02::1 All lokal Devices (eigentlich der Ersatz des Broadcast)
  FF02::2 All Routers

Weiterlesen

In diesem Artikel möchte ich auf die Basiskonfiguration von Frame-Relay, einer NBMA (Non-Broadcast-Multiple-Access) eingehen.
Diese Technologie kommt im WAN (Wide Area Network) zum Einsatz und unterstützt wie der Name schon andeutet keine Broadcast aber auch keine Multicast Daten.
Im Frame-Relay reden wir bei den Verbindungen normalerweise von PVC’s (Permanent Virtual Circuit). Das bedeutet dass der ISP uns innerhalb seines Netzwerkes eine permanente Verbindung über “Frame-Relay Switche” bereitstellt um von A nach B zu kommen.
Für diese Verbindung nennt er uns, falls benötigt 2 DLCI’s (Data-Link Connection Identifier) durch die unsere Pakete den Weg finden.
Die genannten DLCI’s sind immer nur lokal zu betrachten.

Bsp:
Die Firma Radium-Networks erfragt bei einem ISP eine Full-Mesh Frame-Relay Verbindung vom HQ in Berlin zu den Außenstellen in München und Frankfurt.
Der ISP gibt an dass unsere Router im HQ über die DLCI 102 die Verbindung nach München erreichen und über DLCI 103 nach Frankfurt.
Gleichzeitig können die Router in Frankfurt über die DLCI 102 die Router in München erreichen und DLCI 205 die Router in Berlin.

Lokal dürfen also die DLCI’s nicht doppelt vorkommen, aber global im ISP Netzwerk schon.

Oft ist es jedoch nicht einmal notwendig, dass der ISP die DLCI Nummern bekanntgibt. Je nach Konfiguration kann ein automatisches Verfahren, Inverse Arp, genutzt werden damit die Access Router in meinem Netzwerk die DLCI’s und damit die Verbindungen automatisch herausfinden.

Inverse Arp:

1. Der Router fragt den Frame Relay Switch nach den lokalen DLCI’s
2. Der Router sendet daraufhin ein Hello mit eigener IP an die DLCI’s
3. Der Frame Relay Switch sendet es zur anderes Seite des PVC (möglicherweise durch ein hochkomplexes Netzwerk des ISP das uns durch diese Technik gar nicht interessieren muss)
4. Der andere Router erhält das Hello Packet und weiß über die IP und das zugehörige lokale DLCI.

Sollte es doch notwendig werden die DLCI’s fest einzutragen, werden bei Multipoint Interfaces der Befehl “frame-relay map ip [DestIP] [LokalDLCI] broadcast”
und bei Point2Point Interfaces der Befehl “frame-relay interface-dlci [lokalDLCI]” verwendet.

Bei der Konfiguration von Frame-Relay gibt es verschiedene Standard’s wie die LMI Typen die zu einander passen müssen. Zur Fehlersuche lohnt daher auch ein Blick auf “show interfaces [Frame-Relay Interface]” beziehungsweise auf die debug Möglichkeiten:

• debug frame-relay events
• debug frame-relay packet
• debug frame-relay lmi

oder auch die Möglichkeit die durch Inverse Arp “gelernten” Mappings mittels “clear frame-relay inarp” zu löschen.

Der Bereich Frame-Relay wird noch tiefergehend in den nächsten Artikel behandelt. Hier schauen wir uns erstmal ein kleines Szenario zur Konfiguration von physikalischen Interfaces mit Inverse Arp, Multipoint und auch Point-to-Point Interfaces an.

Weiterlesen

OSPF oder auch Open Shortest Path First ist ein Link-State-Routing Protokoll. Ein Link-State-Routing Protokoll ist dadurch gekennzeichnet, dass es eine Topologietabelle pflegt. Zwar hat auch EIGRP eine Topologietabelle aber dort befinden sich nur Informationen zu den besten bzw zu Backuprouten zu den Zielnetzwerken. In der Topologietabelle von OSPF befindet sich eine komplette Abbildung “Landkarte” der OSPR Area.
Im folgenden möchte ich wieder mit Begriffserklärungen zu OSPF beginnen.

AS (Autonomes System): Umfasst das OSPF Netzwerk und die darin enthaltenen Area’s
Area: Umfasst eine Zone in welcher jeder Router der Zone alle Informationen d.h. die gleiche Topologiedatenbank hat.
Segment: Beinhaltet ein Subnetz das über einen oder mehrere Router direkt angeschlossen ist.

OSPF Tabellen

• Neighbor Table: enthält Informationen zu direkten Nachbarn, d.h. Routern die direkt erreichbar und in der gleichen Area sind.
• Topology Table: enthält Informationen für die komplette Area ähnlich einer Landkarte.
• Routing Table: enthält die genutzten Routen des Systems.

Zur Berechnung der Routen nutzt OSPF den Dijkstra-Algorithmus Shortest Path First. Um Ressourcen und Bandbreite zu sparen sendet OSPF getriggerte Updates wenn eine Änderung erfolgt ist und nur in sehr langen Abständen (30min) automatische Updates um sicherzustellen das alles korrekt arbeitet.

Für die interne Berechnung und Routing Logik von OSPF, müssen wir uns die “Kosten” einer Verbindung laut OSPF ansehen.

OSPF Kosten

Die Standardkosten sind 100 / Bandwidth (Mbit/sec).

Dies führt zur folgenden Liste:

• 56k = 1785
• 64k = 1562
• T1 (1544k) = 65
• Ethernet = 10
• FastEthernet = 1

Die Berechnung der Kosten für eine OSPF Route kann über den Router Befehl
“R1(config-router)#auto-cost reference-bandwidth 10000″ von dem Standardwert 100 geändert werden.
Falls der neue Ausgangswert für die Kosten jedoch zu hoch angesetzt wird, kann es passieren dass eine langsame Verbindung z.B. 56k einen zu hohen Wert für die Kosten enthält und vom Router als unreachable angesehen wird.

OSPF Pakete

• Hello: Aufbau der Partnerschaft
• DBD: (Database Description Packet) Kurzbeschreibung der Routinginformationen
• LSR: (Link State Request)
• LSU: (Link State Update) Enthält ein oder mehrere LSA’s
• LSA: (Link State Advertisement) Enthält detailierte Informationen zu einer Route
• LSAck: (Link State Acknowledgement)

Die LSA’s sind wiederum in verschiedene Typen unterteilt:

• LSA Type1: Router LSA (jeder OSPF Router stellt hiermit Informationen über sich innerhalb der Area bereit)
• LSA Type2: Network LSA (der DR Designated Router stellt hiermit Informationen zur Area und den enthaltenen Routern bereit)
• LSA Type3: Summary LSA (ABR Summary Route) (Zusammenfassung der Routen durch den ABR)
• LSA Type4: Summary LSA (ASBR Location) (Ankündigung eines ASBR mit der Information des Next Hop’s)
• LSA Type5: Summary LSA (ASBR Summary Route (für Externe Routen))
• LSA Type7: Tunnel LSAs (Type 5 LSAs dass durch eine NSSA (Not so Stubby Area) getunnelt wird)

Das OSPF Netzwerk kann eine oder auch mehrere Area’s enthalten. Die erste und definitiv notwendige Area ist die Area 0. Alle weiteren Zonen müssen über ABR‘s (Area Border Router) angeschlossen werden. Ein Router der an der Grenze des AS ist und die Schnittstelle z.B. zum Internet oder zu anderen Routingprotokollen darstellt, wird als ASBR (Autonomous System Boundary Router) bezeichnet.

OSPF Areas

• Normal: Normale Area in der alle LSA zugelassen sind.
• Stub: LSA Type 5 wird vom ABR geblockt. D.h. keine O E1 / O E2 Routen
• Totally Stub: LSA Type 3,4 und 5 werden vom ABR geblockt.
  D.h. keine O E1 / O E2 Routen und nur eine zusammengefasste O*IA Route
• Not So Stubby (NSSA): Wie Stub aber LSA Type 5 werden als Typ 7 getunnelt.
  (Wird eingesetzt wenn ein ASBR in der Zone vorhanden ist.)
• NSSA Totally Stub: Wie Totally Stub aber LSA Type 5 werden als Typ 7 getunnelt.
  (Wird eingesetzt wenn ein ASBR in der Zone vorhanden ist.)

Innerhalb eines Segments (Subnetzwerk) einer OSPF Area (Ausnahme Point2Point Link) erfolgt die Wahl eines DR (Designated Router) und BDR (Backup Designated Router) die für den Austausch von Informationen zuständig sein. Dazu später.

Die Erstellung einer Partnerschaft zwischen OSPF Router ist etwas komplexer als bei EIGRP.

Weiterlesen

Um mit dem Routingprotokoll EIGRP (Enhanced Interior Gateway Routing Protocol) zu arbeiten, müssen vorher ein paar Begriffe beschrieben werden.
EIGRP wird als “erweitertes Distance-Vector” oder auch “hybrid-balanced” Routingprotokoll bezeichnet da es zwar ein Distance-Vector Protokoll ist, jedoch auch einige positive Eigenschaften eines Link-State Routing Protokolls hat. EIGRP arbeitet innerhalb autonomen Systemen (AS) die über eine Nummer definiert sind. Generell tauschen nur Router ihre EIGRP Routen aus die auch im gleichen AS sind.

EIGRP arbeitet mit 3 Tabellen

• Neighbor Table: enthält Informationen zu direkten Nachbarn, d.h. Routern die direkt erreichbar sind im gleichen “autonomen System” sind.
• Topology Table: enthält Informationen zu den Successor Routen (Primäre Route) und Feasible Successor Routen (Backup Routen)
• Routing Table: enthält die genutzten Routen des Systems.

Um eine Route einzuschätzen hat auch EIGRP eine Berechnung für die Metric.
In der Formel zur Berechnung der EIGRP Metric sind 4 Faktoren enthalten: Bandwidth, Delay, Reliability und Load.
In er Standardkonfiguration kann jedoch die Formel:

EIGRP Metric = 256*([K1*Bw + K2*Bw/(256-Load) + K3*Delay]*[K5/(Reliability + K4)]) ->zu  EIGRP Metric = 256*(Bw + Delay)

reduziert werden, da in der Basiskonfiguration K1 = 1; K2 = 0; K3 = 1; K4 = 0 und K5 = 0 ist.

Als “Feasible Distance” werden die “Kosten” der Route vom Router zum gewünschten Netzwerk bezeichnet.
Die “Advertised Distance” bezeichnet die Metric eines Nachbarrouters von ihm zum gewünschten Netzwerk.

Die Successor Route für das gewünschte Netzwerk ist daher die Route mit der kleinsten Feasible Distance.
Ein Feasible Successor ist eine Route die nicht die kleinste Feasible Distance für das gewünschte Netzwerk hat aber in der die Advertised Distance noch kleiner als die Feasible Distance der Successor Route ist und damit ein Rooting Loop verhindert.

Innerhalb der EIGRP Topologie Tabelle werden die Routen als Active oder Passive gekennzeichnet.

• Active bedeutet, dass nach einer Backup Route gesucht wird da für das Ziel die Successor Route und eventuelle Feasible Successor Routen ausgefallen sind.
• Passiv bedeutet, dass die Successor Route stabil ist.

EIGRP arbeitet mit 5 verschiedenen Paketen die über die Multicast Adresse 224.0.0.10 verschickt werden und dadurch durch jeden benachbarten EIGRP Router gelesen werden.

• Hello: wird für die Konfiguration der Beziehung zwischen den Nachbarroutern verwendet.
• Update: beinhaltet Updates mit Advertised Distances zu den bekannten Netzwerken.
• Query: wird verwendet um einen Nachbarrouter nach einer Backup Route zu fragen.
• Reply: enthält die Antwort zu einem Query
• Ack: Bestätigt Update,Query und Reply Pakete

Während der Formung der EIGRP Beziehung zwischen 2 Routern werden daher nur 3 Paketarten verwendet.

1. Beide Router schicken sich gegenseitig “Hello” Pakete um sich gegenseitig bekanntzumachen.
2. Router A schickt seine Routen mit einer Advertised Distance an Router B und Router B schickt “Ack” Pakete zur Bestätigung.
3. Router B schickt seine Routen mit einer Advertised Distance an Router A und Router A schickt seinerseits “Ack” Pakete zur Bestätigung.

Genug der Theorie: Hier gehts zum Szenario