"Präfixe für lokale Richtlinien verweigert" in der Ausgabe "show ip bgp neighbour"

Ich habe die letzte Woche damit verbracht, einige (möglicherweise verwandte, aber wahrscheinlich nicht) Probleme mit Quagga zu beheben. Ich habe einen Testrouter - 7204VXR-NPEG2 mit 12.4 (24) T6 - mit einer einzelnen BGP-Sitzung zu einem Quagga-Host. Die einzige BGP-Sitzung auf dem 7204 ist mit der Quagga-Box. Dies ist eine eBGP-Sitzung. Auf beiden Seiten ist buchstäblich keine Richtlinie konfiguriert, aber ich erhalte diese ohne Fehler bei der show ip bgp neighbor x.x.x.xAusgabe:

                                   Outbound    Inbound
  Local Policy Denied Prefixes:    --------    -------
    Bestpath from this peer:          19270        n/a
    Total:                            19270          0

Zufällig (oder vielleicht auch nicht?) Entspricht diese Nummer immer der Anzahl der Präfixe, die ich vom Peer erhalte ( show ip bgp summary). Es gibt einige Gründe, warum dies wirklich rätselhaft ist:

1) Wie gesagt, es gibt keine Politik. Dies ist meine BGP / Nachbar-Konfiguration:

router bgp XXXXX
 no synchronization
 bgp router-id X.X.X.X
 no bgp enforce-first-as
 bgp log-neighbor-changes
 neighbor X.X.X.X remote-as XXXXX
 neighbor X.X.X.X next-hop-self
 neighbor X.X.X.X soft-reconfiguration inbound
 no auto-summary

2) Der 7204 kündigt nichts an - er soll nur Präfixe empfangen.

Möchte jemand etwas Licht ins Dunkel bringen, was dies bedeutet? Ist das normale / erwartete Ausgabe? Eine Google-Suche brachte mir nur einen kleinen Teil der Informationen, die ich von CCO erhalten hatte:

Bester Pfad von diesem Peer
Zeigt eingehende Ablehnungen an, da der beste Pfad vom lokalen Router stammt.

Dies wäre sinnvoll ... für eingehende. Was ist mit Outbound? Ich kann leicht sehen, dass dies ein dummer Fehler ist, aber ich dachte, ich würde mich an andere Leute wenden, um zu sehen, ob sie das schon einmal gesehen haben.

bgp cisco-commands cisco-ios-12

— John Jensen
quelle

Hat dir eine Antwort geholfen? Wenn ja, sollten Sie die Antwort akzeptieren, damit die Frage nicht für immer auftaucht und nach einer Antwort sucht. Alternativ können Sie Ihre eigene Antwort bereitstellen und akzeptieren.

— Ron Maupin

Antworten:

Dies ist höchstwahrscheinlich darauf zurückzuführen, dass der EBGP-Split-Horizon aktiviert wird ... dh der 7204-Router empfängt diese Präfixe von Quagga, wählt den besten Pfad aus und versucht, sie bekannt zu machen. Da der einzige Nachbar der Nachbar ist, von dem der beste Pfad empfangen wurde, werden die Anzeigen gefiltert. Der Zähler oben zeigt das.

— Pradosh Mohapatra
quelle

Ich denke, dies ist ein guter Vorschlag, aber mit dieser Logik würde jeder eBGP-Peer dieses Zählerinkrement für jede eBGP-Sitzung haben, nicht wahr?

— John Jensen

Nein. Wenn Sie zwei eBGP-Sitzungen haben, die jeweils 100 eindeutige Präfixe erhalten (für insgesamt 200 eindeutige Präfixe) und ein einzelnes Präfix erstellen, würden Sie jedem BGP-Peer genau 101 Präfixe bekannt geben. In Ihrem Beispiel haben Sie einen einzelnen eBGP-Peer und haben keinen Ursprung. Somit ist dieser Peer der beste Pfad für alle Präfixe. Daher filtert Split-Horizon alle ausgehenden Anzeigen zurück zu diesem Peer.

— Ryan

Wenn Sie mir eine offizielle Dokumentation finden, die Ihre Behauptungen bestätigt, senden Sie bitte eine Antwort und ich werde sie gerne akzeptieren.

— John Jensen

(Oder ich akzeptiere diese Antwort, da Ihre Antwort im Wesentlichen dieselbe sein würde wie die von Pradosh)

— John Jensen

Ich werde noch eine Sache hinzufügen, weil mir klar ist, dass meine Kommentare möglicherweise unhöflich sind, aber es ist wirklich nur aus meiner Frustration heraus, dass ich dies nicht verstehe. Zuerst dachte ich, das no bgp enforce-first-assei schuld, aber nachdem ich das von @Ryan beschriebene Szenario ohne ausgeschalteten Knopf neu erstellt habe, habe ich sicherlich mehr Fragen als Verständnis, und ein Mangel an Dokumentation zu diesem Verhalten trägt ebenfalls zur Frustration bei.

— John Jensen

Ich gehe davon aus, dass Sie IBGP ausführen. Sie senden niemals ein Präfix, das Sie über IBGP erhalten haben, an einen IBGP-Nachbarn. Außerdem gibt es einen geteilten Horizont (senden Sie keine Route zurück an die Person, die es an Sie gesendet hat). Da dieses Feld nur einen Nachbarn hat und keine eigenen Routen erstellt, werden keine Routen gesendet, sodass die Richtlinie implizit ist, aber dort.

— Fredpbaker
quelle

Dies ist eigentlich eine eBGP-Sitzung - hätte das in meiner Frage klarstellen sollen - guter Fang. Ich werde es bearbeiten, um es zu klären. Und in Bezug auf die iBGP-Regel für den geteilten Horizont - ich würde dies glauben, wenn der Grund nicht "bester Pfad von diesem Peer" wäre - dasselbe Dokument in dem Link, den ich gefunden habe, zeigt einen separaten Grund für den geteilten iBGP-Horizont - "* Bester Pfad von iBGP-Peer-Bereitstellungen eingehende Ablehnungen, weil der beste Pfad von einem iBGP-Nachbarn stammt. " - siehe groupstudy.com/archives/ccielab/200511/msg00629.html

— John Jensen