Gelernte eBGP-Routen, die nicht an iBGP-Nachbarn verteilt wurden

8

Ich habe (in GNS3) drei Cisco 3640s mit 12.4 (23) in Reihe geschaltet (R1 -> R2 -> R3). R1 und R2 sind eBGP-Peers, R2 und R3 sind iBGP-Peers. R1 wirbt für das Netzwerk 192.168.1.0/24. R2 empfängt diese Route, macht sie jedoch nicht auf R3 aufmerksam.

Sollten aus eBGP gelernte Routen nicht für iBGP beworben werden?

Hier ist die vollständige Konfiguration wie eingegeben:

loop0(R1)s0/0 <--> s0/0(R2)s0/1 <--> s0/1(R3)

R1:
configure terminal
interface s0/0
ip address 172.16.1.1 255.255.255.252
no shutdown
interface loopback0
ip address  192.168.1.1 255.255.255.0
router bgp 1
neighbor 172.16.1.2 remote-as 2
network 192.168.1.0 mask 255.255.255.0

R2:
configure terminal
interface s0/0
ip address 172.16.1.2 255.255.255.252
no shutdown
interface s0/1
ip address 172.16.1.5 255.255.255.252
no shutdown
router bgp 2
neighbor 172.16.1.1 remote-as 1
neighbor 172.16.1.6 remote-as 2

R3:
configure terminal
interface s0/1
ip address 172.16.1.6  255.255.255.252
no shutdown
router bgp 2
neighbor 172.16.1.5 remote-as 2

— user1038451
quelle

14

Angenommen, Sie haben kein IGP konfiguriert (wie EIGRP / OSPF / ISIS / RIP), dann ist die einfachste Erklärung, dass R3 keine Route zum nächsten Hop von 192.168.1.0/24 hat, wenn das iBGP-Update bei R3 eintrifft.

loop0(R1)s0/0 <-----------> s0/0(R2)s0/1 <-------------> s0/1(R3)
    AS 1                       AS 2                        AS 2

              --------->                  ----------->
              Prefix: 192.168.1.0/24      Prefix: 192.168.1.0/24
              AS-path: 1                  AS-path: 1
              Next-hop: 172.16.1.1        Next-hop: 172.16.1.1
              *via eBGP*                  *via iBGP*

Da iBGP den nächsten Hop nicht zurücksetzt, wenn es das Update von R1 empfängt, muss der nächste Hop (172.16.1.1) von 192.168.1.0/24 erreichbar sein ( weitere Informationen finden Sie unter Warum Router BGP-Pfade ignorieren ).

Der einfachste Weg, dies zu testen, besteht darin, eine Statik auf R3 zu konfigurieren:

ip route 172.16.1.0 0.0.0.3 172.16.1.5 name BAD_HACK_FOR_IBGP

Das ist natürlich die falsche Lösung, aber es ist ein kinderleichter Test, um zu veranschaulichen, warum Probleme auftreten (denken Sie daran, dass Sie möglicherweise etwas warten müssen, bis der BGP-Next-Hop-Scanner ausgeführt wird, bevor die Route von 192.168.1.0/24 installiert wird). .

Es gibt zwei mögliche Lösungen, die in den Sinn kommen, aber nur eine ist in den meisten Netzwerken wirklich sinnvoll ...

Beste Lösung : Konfigurieren Sie ein IGP ... wählen Sie ein beliebiges IGP aus und bewerben Sie 172.16.1.0/30 in AS 2 in diesem IGP
Optionale Lösung : Konfigurieren Sie die Peering-Sitzung zwischen R2 und R3 zum Festlegennext-hop-self

Die Erreichbarkeit des nächsten Hops ist eines der grundlegendsten Probleme beim Verständnis von BGP. Fast jeder stößt auf dieses Problem, wenn er mit dem Protokoll experimentiert.

— Mike Pennington
quelle

1

Hervorragende Erklärung. Mir war nicht bewusst, dass iBGP den nächsten Hop unverändert besteht.

— user1038451

Mike, könnten Sie ein Beispiel dafür geben, wann Sie es nicht verwenden möchten next-hop-self(außer weil bereits ein IGP für die Next-Hop-Adresse des eBGP-Peers wirbt)? Ich wollte zunächst eine andere Frage stellen, dachte aber, es wäre eine einfache Ergänzung zu Ihrer Antwort. Nachdem ich kürzlich BGP herausgeholt habe und immer wieder darauf stoße, bin ich neugierig, warum dies next-hop-self nicht das Standardverhalten war.

— Eddie

Ich kann Informationen dazu hinzufügen, aber es kann einige Tage dauern, bis ich Zeit habe. Kurzgeschichte: Die IGP-Kosten für den nächsten BGP-Hop sind Teil des Standard-eBGP-Pfadauswahlalgorithmus

— Mike Pennington,

0

Sie sollten Ihre verbundenen Schnittstellen auf R2 ankündigen müssen. weil das einzige Netzwerk 192.168.1.0 jetzt nicht was ist der nächste Hop. Sie können mit "show ip bgp" auf R3 überprüfen .

Wie Sie sehen können, 192.168.1.0 in der R3-BGP-Tabelle, jedoch nicht in die Routing-Tabelle eingefügt. Weil es nicht weiß, was der nächste Sprung ist

Lösung:

Verteilen Sie verbundene Schnittstellen auf R2 neu
Sagen Sie EBGP-Nachbar, wer der nächste Hop als " Nachbar 172.16.1.2 next-hop-self " auf R1 ist .

— Deniz KAYDIRAK
quelle