<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Unicast Routing on bitunfall.de</title><link>https://bitunfall.de/schlagworte/unicast-routing/</link><description>Recent content in Unicast Routing on bitunfall.de</description><generator>Hugo</generator><language>en</language><lastBuildDate>Mon, 29 Jun 2026 13:47:53 +0200</lastBuildDate><atom:link href="https://bitunfall.de/schlagworte/unicast-routing/index.xml" rel="self" type="application/rss+xml"/><item><title>JNCIP-ENT: Unicast‑ und Multicast‑Routing</title><link>https://bitunfall.de/werkbank/jncip-ent-unicast-und-multicastrouting/</link><pubDate>Mon, 29 Jun 2026 13:47:53 +0200</pubDate><guid>https://bitunfall.de/werkbank/jncip-ent-unicast-und-multicastrouting/</guid><description>&lt;p&gt;Unicast‑ und Multicast‑Routing werden oft getrennt betrachtet, obwohl sie im praktischen Betrieb untrennbar miteinander verknüpft sind. Besonders deutlich wird das im Zusammenspiel zwischen Multicast-Routing-Protokollen und dem zugrunde liegenden Unicast-Routing. Multicast berechnet keine eigene vollständige Topologie, sondern nutzt die Informationen, die bereits im Netzwerk vorhanden sind. Daraus entsteht eine Abhängigkeit, die häufig unterschätzt wird und viele Fehlerbilder erklärt.&lt;/p&gt;
&lt;p&gt;Die Grundlage dieses Zusammenspiels ist die Tatsache, dass Multicast-Pfade nicht eigenständig bestimmt werden. Stattdessen orientieren sie sich an den bestehenden Unicast-Routen. Ein Router entscheidet beim Empfang eines Multicast-Pakets, ob es gültig ist, indem er überprüft, ob es über den erwarteten Weg eingetroffen ist. Dieser Mechanismus wird als Reverse Path Forwarding bezeichnet. Dabei wird nicht der Weg zum Ziel geprüft, sondern der hypothetische Rückweg zur Quelle. Kommt ein Paket nicht über das Interface an, das der Router selbst für den Weg zur Quelle nutzen würde, wird es verworfen.&lt;/p&gt;</description></item></channel></rss>