<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Local Preference on bitunfall.de</title><link>https://bitunfall.de/schlagworte/local-preference/</link><description>Recent content in Local Preference on bitunfall.de</description><generator>Hugo</generator><language>en</language><lastBuildDate>Tue, 30 Jun 2026 21:23:35 +0200</lastBuildDate><atom:link href="https://bitunfall.de/schlagworte/local-preference/index.xml" rel="self" type="application/rss+xml"/><item><title>JNCIP-ENT: iBGP Probleme &amp; Route Reflektoren</title><link>https://bitunfall.de/werkbank/jncip-ent-ibgp-probleme-route-reflektoren/</link><pubDate>Tue, 30 Jun 2026 21:23:35 +0200</pubDate><guid>https://bitunfall.de/werkbank/jncip-ent-ibgp-probleme-route-reflektoren/</guid><description>&lt;p&gt;BGP‑Entscheidungen wirken auf den ersten Blick konsistent und deterministisch, werden in der Praxis jedoch oft falsch eingeschätzt, weil mehrere Mechanismen gleichzeitig greifen. Das Protokoll bewertet Routen nicht anhand eines einzelnen Kriteriums, sondern durchläuft eine klar definierte Kette von Attributen. Entscheidend ist dabei nicht nur, welches Attribut „wichtiger“ ist, sondern vor allem, in welcher Reihenfolge überhaupt verglichen wird. Viele scheinbar unerklärliche Routing‑Entscheidungen lassen sich genau auf diese Reihenfolge zurückführen.&lt;/p&gt;
&lt;p&gt;Im Gegensatz zu &lt;em&gt;Link-State-Protokollen&lt;/em&gt; wie OSPF, die primär auf einer einheitlichen Metrik basieren, ist BGP ein Policy-gesteuertes Protokoll. Das bedeutet, dass es darauf ausgelegt ist, administrative Entscheidungen abzubilden, nicht zwingend die technisch kürzeste oder schnellste Route zu wählen. Die Path Selection ist daher bewusst mehrstufig aufgebaut und priorisiert zunächst Attribute, die durch den Betreiber beeinflusst werden können.&lt;/p&gt;</description></item></channel></rss>