<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Routing Policy on bitunfall.de</title><link>https://bitunfall.de/schlagworte/routing-policy/</link><description>Recent content in Routing Policy on bitunfall.de</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sun, 28 Jun 2026 13:25:37 +0200</lastBuildDate><atom:link href="https://bitunfall.de/schlagworte/routing-policy/index.xml" rel="self" type="application/rss+xml"/><item><title>JNCIP-ENT: Policy Debugging</title><link>https://bitunfall.de/werkbank/jncip-ent-policy-debugging/</link><pubDate>Sun, 28 Jun 2026 13:25:37 +0200</pubDate><guid>https://bitunfall.de/werkbank/jncip-ent-policy-debugging/</guid><description>&lt;p&gt;Viele Netzwerkprobleme entstehen nicht durch einzelne Fehlkonfigurationen, sondern durch das Zusammenwirken scheinbar korrekter Mechanismen. Routing funktioniert selten isoliert innerhalb eines Protokolls. Stattdessen greifen mehrere Ebenen ineinander: Protokollverhalten, Policy, Next-Hop-Auflösung und Forwarding. Genau aus diesem Zusammenspiel ergeben sich typische Fehlerbilder, die sich nicht auf den ersten Blick erklären lassen.&lt;/p&gt;
&lt;p&gt;Ein häufiges Missverständnis besteht darin, Routing als einen linearen Ablauf zu betrachten. In der Realität handelt es sich um eine Kette voneinander abhängiger Entscheidungen. Eine Route wird empfangen, durch Policies verarbeitet, bewertet, ausgewählt und schließlich technisch umgesetzt. An jeder dieser Stellen kann sie scheitern, ohne dass die vorherigen Schritte fehlerhaft waren. Diese Trennung ist entscheidend, denn sie erklärt, warum eine scheinbar korrekte Konfiguration zu unerwartetem Verhalten führen kann.&lt;/p&gt;</description></item><item><title>JNCIP-ENT: Routing Policies in Junos</title><link>https://bitunfall.de/werkbank/jncip-ent-routing-policies-in-junos/</link><pubDate>Fri, 26 Jun 2026 13:25:06 +0200</pubDate><guid>https://bitunfall.de/werkbank/jncip-ent-routing-policies-in-junos/</guid><description>&lt;p&gt;Routing Policies sind in Junos kein ergänzendes Feature, sondern der Mechanismus, mit dem Routingverhalten tatsächlich kontrolliert wird. Während Protokolle wie OSPF oder BGP definieren, wie Informationen ausgetauscht werden, bestimmen Policies, welche dieser Informationen akzeptiert, verändert oder verworfen werden. Ohne dieses Konzept wäre Routing ausschließlich durch Protokolllogik gesteuert und kaum an reale Anforderungen anpassbar.&lt;/p&gt;
&lt;p&gt;Der Aufbau einer Policy folgt einem einfachen, aber strikt eingehaltenen Prinzip. Eine Policy besteht aus mehreren Termen, die sequenziell ausgewertet werden. Jeder Term enthält eine Bedingung und eine Aktion. Sobald eine Route die Bedingung eines Terms erfüllt, wird die zugehörige Aktion ausgeführt. Entscheidend ist dabei, dass die Abarbeitung in diesem Moment standardmäßig endet. Die nachfolgenden Terme werden nicht mehr betrachtet, es sei denn, das Verhalten wird explizit anders definiert. Diese Eigenschaft führt dazu, dass die Reihenfolge der Terme oft wichtiger ist als deren Inhalt.&lt;/p&gt;</description></item><item><title>Routing Policies auf Junos</title><link>https://bitunfall.de/werkbank/routing-policies-auf-junos/</link><pubDate>Fri, 19 Jun 2026 17:57:21 +0200</pubDate><guid>https://bitunfall.de/werkbank/routing-policies-auf-junos/</guid><description>&lt;p&gt;Nach den ersten Schritten mit OSPF, IS-IS und BGP entsteht häufig der Eindruck, Routing sei ein weitgehend automatischer Prozess. Routingprotokolle tauschen Informationen aus, berechnen die besten Pfade und erstellen daraus Routingtabellen. In kleinen Netzwerken mag diese Vorstellung ausreichend sein.&lt;/p&gt;
&lt;p&gt;In Service-Provider-Netzen funktioniert Routing jedoch deutlich kontrollierter. Provider akzeptieren nicht jede Route, die ihnen angeboten wird. Sie geben nicht jede Route an ihre Nachbarn weiter und sie verlassen sich nicht darauf, dass Routingprotokolle immer die gewünschten Entscheidungen treffen.&lt;/p&gt;</description></item><item><title>BGP Grundlagen - Das Rückgrat des Internets</title><link>https://bitunfall.de/werkbank/bgp-grundlagen-das-ruckgrat-des-internets/</link><pubDate>Wed, 17 Jun 2026 17:56:23 +0200</pubDate><guid>https://bitunfall.de/werkbank/bgp-grundlagen-das-ruckgrat-des-internets/</guid><description>&lt;p&gt;Wenn OSPF und IS-IS die Straßen innerhalb einer Stadt darstellen, dann ist BGP das internationale Verkehrsnetz zwischen Ländern. Kaum ein anderes Routingprotokoll hat die Entwicklung des modernen Internets so nachhaltig geprägt wie das Border Gateway Protocol.&lt;/p&gt;
&lt;p&gt;Jeder Aufruf einer Website, jede Cloud-Verbindung und nahezu jede Kommunikation zwischen unterschiedlichen Netzbetreibern basiert letztlich auf BGP. Ohne dieses Protokoll würde das Internet in seiner heutigen Form nicht existieren.&lt;/p&gt;
&lt;p&gt;Für die JNCIS-SP-Zertifizierung stellt BGP einen der wichtigsten Themenbereiche überhaupt dar. Gleichzeitig ist es eines der am häufigsten missverstandenen Routingprotokolle. Viele Administratoren versuchen zunächst, BGP mit OSPF oder IS-IS zu vergleichen. Genau hier beginnen jedoch häufig die ersten Verständnisprobleme.&lt;/p&gt;</description></item><item><title>Route Redistribution in Junos</title><link>https://bitunfall.de/werkbank/route-redistribution-in-junos/</link><pubDate>Tue, 02 Jun 2026 18:20:36 +0200</pubDate><guid>https://bitunfall.de/werkbank/route-redistribution-in-junos/</guid><description>&lt;div class="subtitle"&gt;
 Wenn Routing-Protokolle miteinander sprechen müssen
&lt;/div&gt;
&lt;h2 id="einleitung"&gt;Einleitung&lt;/h2&gt;
&lt;p&gt;Bisher haben wir die großen Routing-Protokolle der JNCIS-ENT einzeln betrachtet:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;OSPF&lt;/li&gt;
&lt;li&gt;IS-IS&lt;/li&gt;
&lt;li&gt;BGP&lt;/li&gt;
&lt;li&gt;Statische Routen&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;In Lehrbüchern wirken diese Protokolle oft wie voneinander getrennte Welten.&lt;/p&gt;
&lt;p&gt;Die Realität sieht jedoch anders aus.&lt;/p&gt;
&lt;p&gt;In produktiven Netzwerken existieren häufig mehrere Routing-Protokolle gleichzeitig.&lt;/p&gt;
&lt;p&gt;Ein typisches Enterprise-Netzwerk könnte beispielsweise so aussehen:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre tabindex="0" class="chroma"&gt;&lt;code class="language-text" data-lang="text"&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;Campus
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;(OSPF)
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt; |
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt; |
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;Core
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;(IS-IS)
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt; |
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt; |
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;Edge
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;(BGP)
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt; |
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;Internet
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;Plötzlich entsteht eine wichtige Frage:&lt;/p&gt;</description></item></channel></rss>