<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Next-Hop-Self on bitunfall.de</title><link>https://bitunfall.de/schlagworte/next-hop-self/</link><description>Recent content in Next-Hop-Self on bitunfall.de</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sun, 28 Jun 2026 13:24:10 +0200</lastBuildDate><atom:link href="https://bitunfall.de/schlagworte/next-hop-self/index.xml" rel="self" type="application/rss+xml"/><item><title>JNCIP-ENT: Next-Hop Probleme in der Praxis</title><link>https://bitunfall.de/werkbank/jncip-ent-next-hop-probleme-in-der-praxis/</link><pubDate>Sun, 28 Jun 2026 13:24:10 +0200</pubDate><guid>https://bitunfall.de/werkbank/jncip-ent-next-hop-probleme-in-der-praxis/</guid><description>&lt;p&gt;BGP operiert nicht isoliert, sondern ist in hohem Maße von den darunterliegenden Routingmechanismen abhängig. Besonders deutlich wird das beim Next-Hop-Attribut, das eine zentrale Rolle in der praktischen Weiterleitung spielt, aber häufig falsch interpretiert wird. Viele Probleme, bei denen BGP scheinbar korrekt funktioniert, lassen sich letztlich darauf zurückführen, dass der Next-Hop zwar logisch vorhanden, aber faktisch nicht nutzbar ist.&lt;/p&gt;
&lt;p&gt;Das Next-Hop-Attribut beschreibt den nächsten Router auf dem Weg zum Zielpräfix. Es ist kein optionales Detail, sondern die eigentliche Grundlage der Forwarding-Entscheidung. Während BGP selbst nur entscheidet, welcher Pfad bevorzugt wird, verlässt es sich darauf, dass der Next-Hop über das zugrunde liegende Routing erreichbar ist. Diese Trennung führt dazu, dass eine Route innerhalb von BGP vollkommen valide erscheinen kann, aber dennoch nicht verwendet wird, weil die Erreichbarkeit des Next-Hops nicht gewährleistet ist.&lt;/p&gt;</description></item></channel></rss>