3. Examples (Beispiele)

3. Examples (Beispiele)

Eine Eigenschaft wie "NSFNET sponsored/AUP" könnte allen AUP-konformen (Acceptable Use Policy) Zielen hinzugefügt werden, die in das NSFNET beworben werden. NSFNET-Betreiber könnten eine Richtlinie definieren, die alle Routen, ob markiert oder nicht, an direkt verbundene AUP-konforme Kunden bewirbt und nur markierte Routen an kommerzielle oder externe Standorte. Dies würde sicherstellen, dass mindestens eine Seite einer gegebenen Verbindung AUP-konform ist, als eine Möglichkeit, die NSF-Transit-Richtlinien durchzusetzen.

In diesem Beispiel haben wir gerade die Hauptmotivation für eine komplexe Policy-Routing-Datenbank eliminiert, die verwendet wird, um riesige präfix- und AS-pfadbasierte Filterregeln zu generieren. Wir haben auch die Verzögerungen eliminiert, die durch die Out-of-Band-Wartung dieser Datenbank verursacht wurden (Einsenden von NACRs, wöchentliche Konfigurationsläufe usw.).

Ein zweites Beispiel stammt aus der Erfahrung mit Aggregation. Es ist oft nützlich, sowohl ein aggregiertes Präfix als auch die spezifischeren Komponenten-Präfixe zu bewerben, die zur Bildung des Aggregats verwendet wurden, um das "Next Hop"-Routing zu optimieren. Diese Komponenten-Präfixe sind nur für den benachbarten BGP-Peer oder vielleicht das autonome System des benachbarten BGP-Peers nützlich, daher ist es wünschenswert, diese Informationen zu filtern. Durch Angabe eines Community-Werts, den der benachbarte Peer oder die Peers abgleichen und filtern werden, können diese spezifischeren Routen mit der Gewissheit beworben werden, dass sie sich nicht über ihren gewünschten Geltungsbereich hinaus verbreiten.