Inhalt

Einleitung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Konventionen

Das MED-Attribut

Beispiel

Der Befehl bgp deterministic-med

Beispiele

Ein BGP-Router mit deaktiviertem BGP-Determinist-med

BGP-Router mit aktivierter BGP-Deterministik-med

Zugehörige Informationen

Einleitung

In diesem Dokument wird die bgp deterministic-med und erklärt, wie es die Pfadauswahl auf Basis von Multi-Exit Discriminator (MED) beeinflusst.

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle verstehen.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions.

Das MED-Attribut

MED ist ein optionales nichttransitives Attribut. MED ist ein Hinweis an externe Nachbarn auf den bevorzugten Pfad zu einem autonomen System (AS), das mehrere Eintrittspunkte hat. Die MED wird auch als externe Metrik einer Route bezeichnet. Ein niedrigerer MED-Wert wird gegenüber einem höheren Wert bevorzugt.

In diesem Abschnitt wird ein Beispiel dafür beschrieben, wie Sie mit MED die Routing-Entscheidung eines benachbarten AS beeinflussen.

Netzwerktopologie

Netzwerktopologie

Beispiel

In diesem Szenario ist AS 65502 ein Benutzer des ISP mit AS 65501. R4 ist aus Redundanzgründen mit zwei verschiedenen Routern auf der ISP-Seite verbunden und kündigt dem ISP zwei Netzwerke an: 10.4.0.0/16 und 10.5.0.0/16. In diesem Abschnitt werden einige der relevanten Konfigurationen beschrieben.

R4

!

version 12.3

!

hostname r4

!

ip cef

!

!

interface Loopback10

ip address 10.4.0.1 255.255.0.0

!

interface Loopback11

ip address 10.5.0.1 255.255.0.0

!

interface Serial0/0

ip address 192.168.20.4 255.255.255.0

!

interface Serial1/0

ip address 192.168.30.4 255.255.255.0

!

router bgp 65502

no synchronization

bgp log-neighbor-changes

network 10.4.0.0 mask 255.255.0.0

network 10.5.0.0 mask 255.255.0.0

neighbor 192.168.20.2 remote-as 65501

neighbor 192.168.30.3 remote-as 65501

no auto-summary

!

ip classless

!

!

line con 0

exec-timeout 0 0

line aux 0

line vty 0 4

exec-timeout 0 0

login

!

!

end

R2

!

version 12.3

!

hostname r2

!

ip cef

!

!

interface Loopback0

ip address 10.2.2.2 255.255.255.255

!

interface Ethernet0/0

ip address 172.16.0.2 255.255.255.0

!

interface Serial1/0

ip address 192.168.1.2 255.255.255.0

serial restart-delay 0

!

interface Serial2/0

ip address 192.168.20.2 255.255.255.0

serial restart-delay 0

!

router ospf 1

log-adjacency-changes

redistribute connected

passive-interface Serial2/0

network 10.2.2.2 0.0.0.0 area 0

network 172.16.0.2 0.0.0.0 area 0

network 192.168.1.2 0.0.0.0 area 0

network 192.168.20.2 0.0.0.0 area 0

!

router bgp 65501

no synchronization

bgp log-neighbor-changes

neighbor 10.1.1.1 remote-as 65501

neighbor 10.1.1.1 update-source Loopback0

neighbor 10.3.3.3 remote-as 65501

neighbor 10.3.3.3 update-source Loopback0

neighbor 192.168.20.4 remote-as 65502

no auto-summary

!

ip classless

!

!

line con 0

exec-timeout 0 0

transport preferred all

transport output all

line aux 0

transport preferred all

transport output all

line vty 0 4

exec-timeout 0 0

login

transport preferred all

transport input all

transport output all

!

end

Die Konfigurationen von R1 und R3 ähneln denen von R2. R3 hat ein eBGP, das Peers mit R4 bildet, und ein iBGP, das Peers mit R1 bildet.

R1 hat ein iBGP, das als Peer für R2 und einer für R3 fungiert. Achten Sie darauf, was die BGP-Tabellen R1, R2 und R3 für die beiden von R4 angegebenen Netzwerke anzeigen:

r2# show ip bgp 10.4.0.1

BGP routing table entry for 10.4.0.0/16, version 7

Paths: (2 available, best #1, table Default-IP-Routing-Table)

Advertised to non peer-group peers:

10.1.1.1 10.3.3.3

65502

192.168.20.4 from 192.168.20.4 (10.4.4.4)

Origin IGP, metric 0, localpref 100, valid, external, best

65502

192.168.30.4 (metric 74) from 10.3.3.3 (10.3.3.3)

Origin IGP, metric 0, localpref 100, valid, internal

r2# show ip bgp 10.5.0.1

BGP routing table entry for 10.5.0.0/16, version 6

Paths: (2 available, best #2, table Default-IP-Routing-Table)

Advertised to non peer-group peers:

10.1.1.1 10.3.3.3

65502

192.168.30.4 (metric 74) from 10.3.3.3 (10.3.3.3)

Origin IGP, metric 0, localpref 100, valid, internal

65502

192.168.20.4 from 192.168.20.4 (10.4.4.4)

Origin IGP, metric 0, localpref 100, valid, external, best

r3# show ip bgp 10.4.0.1

BGP routing table entry for 10.4.0.0/16, version 8

Paths: (2 available, best #2, table Default-IP-Routing-Table)

Advertised to non peer-group peers:

10.1.1.1 10.2.2.2

65502

192.168.20.4 (metric 74) from 10.2.2.2 (10.2.2.2)

Origin IGP, metric 0, localpref 100, valid, internal

65502

192.168.30.4 from 192.168.30.4 (10.4.4.4)

Origin IGP, metric 0, localpref 100, valid, external, best

r3# show ip bgp 10.5.0.1

BGP routing table entry for 10.5.0.0/16, version 10

Paths: (2 available, best #1, table Default-IP-Routing-Table)

Advertised to non peer-group peers:

10.1.1.1 10.2.2.2

65502

192.168.30.4 from 192.168.30.4 (10.4.4.4)

Origin IGP, metric 0, localpref 100, valid, external, best

65502

192.168.20.4 (metric 74) from 10.2.2.2 (10.2.2.2)

Origin IGP, metric 0, localpref 100, valid, internal

r1# show ip bgp 10.4.0.1

BGP routing table entry for 10.4.0.0/16, version 11

Paths: (2 available, best #1, table Default-IP-Routing-Table)

Not advertised to any peer

65502

192.168.20.4 (metric 128) from 10.2.2.2 (10.2.2.2)

Origin IGP, metric 0, localpref 100, valid, internal, best

65502

192.168.30.4 (metric 128) from 10.3.3.3 (10.3.3.3)

Origin IGP, metric 0, localpref 100, valid, internal

r1# show ip bgp 10.5.0.1

BGP routing table entry for 10.5.0.0/16, version 10

Paths: (2 available, best #2, table Default-IP-Routing-Table)

Not advertised to any peer

65502

192.168.30.4 (metric 128) from 10.3.3.3 (10.3.3.3)

Origin IGP, metric 0, localpref 100, valid, internal

65502

192.168.20.4 (metric 128) from 10.2.2.2 (10.2.2.2)

Origin IGP, metric 0, localpref 100, valid, internal, best

Sowohl R2 als auch R3 wählen als besten Pfad die externe Route von R4 aus, die basierend auf dem BGP-Algorithmus zur Auswahl des besten Pfads erwartet wird. Weitere Informationen finden Sie unter BGP Best Path Selection Algorithm.

Entsprechend wählt R1 R2 für den Zugriff auf die beiden Netzwerke aus. Dies entspricht der BGP-Regel für den besten Pfad: Wählen Sie den Pfad mit der niedrigsten Router-ID aus. Da die R2-Router-ID 10.2.2.2 und die R3-Router-ID 10.3.3.3 lautet, wird R2 ausgewählt. In dieser grundlegenden Konfiguration wird der gesamte Datenverkehr zu den beiden Netzwerken in AS 65502 von R1 bis R2 und dann standardmäßig an R4 weitergeleitet. Angenommen, R4 möchte den Lastenausgleich für den Datenverkehr vornehmen, der von AS 65501 empfangen wird. Um dies ohne Änderungen am R4-ISP zu tun, konfigurieren Sie R4 so, dass er MED verwendet, um den Datenverkehr für ein Netzwerk auf einem Pfad und den Datenverkehr für das andere Netzwerk auf dem anderen Pfad zu erzwingen.

Dies ist die Konfiguration von R4, nachdem Sie die erforderliche Konfiguration angewendet haben:

R4

!

version 12.3

!

hostname r4

!

ip cef

!

!

!

interface Loopback10

ip address 10.4.0.1 255.255.0.0

!

interface Loopback11

ip address 10.5.0.1 255.255.0.0

!

interface Serial0/0

ip address 192.168.20.4 255.255.255.0

!

interface Serial1/0

ip address 192.168.30.4 255.255.255.0

!

router bgp 65502

no synchronization

bgp log-neighbor-changes

network 10.4.0.0 mask 255.255.0.0

network 10.5.0.0 mask 255.255.0.0

neighbor 192.168.20.2 remote-as 65501

neighbor 192.168.20.2 route-map setMED-R2 out

neighbor 192.168.30.3 remote-as 65501

neighbor 192.168.30.3 route-map setMED-R3 out

no auto-summary

!

ip classless

no ip http server

!

!

access-list 1 permit 10.4.0.0 0.0.255.255

access-list 2 permit 10.5.0.0 0.0.255.255

!

route-map setMED-R3 permit 10

match ip address 1

set metric 200

!

route-map setMED-R3 permit 20

match ip address 2

set metric 100

!--- The route-map MED-R3 is applying a MED of 200 to the 10.4.0.0/16

!--- network and a MED of 100 to the 10.5.0.0/16 network.

!--- The route-map is being applied outbound towards R3. ! route-map setMED-R2 permit 10 match ip address 1 set metric 100 ! route-map setMED-R2 permit 20 match ip address 2 set metric 200 !--- The route-map MED-R2 is applying a MED of 100 to the 10.4.0.0/16

!--- network and a MED of 200 to the 10.5.0.0/16 network.

!--- The route-map is being applied outbound towards R2.  ! ! ! line con 0 exec-timeout 0 0 line aux 0 line vty 0 4 exec-timeout 0 0 login ! ! end

Hinweis: Sie müssen die BGP-Sitzung mit dem  clear ip bgp * soft out  , damit diese Konfigurationen aktiv werden.

R1 betrachtet die Route über R2 nun als besten Pfad für das Netzwerk 10.4.0.0/16, da das von R2 empfangene Update eine MED von 100 im Vergleich zu einer MED von 200 hat, was R3 ankündigt. Ebenso verwendet R1 R3 und den Link R3 - R4, um auf 10.5.0.0/16 zuzugreifen:

r1# show ip bgp 10.4.0.1

BGP routing table entry for 10.4.0.0/16, version 14

Paths: (1 available, best #1, table Default-IP-Routing-Table)

Flag: 0x800

Not advertised to any peer

65502

192.168.20.4 (metric 128) from 10.2.2.2 (10.2.2.2)

Origin IGP, metric 100, localpref 100, valid, internal, best

r1#sh ip bgp 10.5.0.1

BGP routing table entry for 10.5.0.0/16, version 13

Paths: (1 available, best #1, table Default-IP-Routing-Table)

Flag: 0x800

Not advertised to any peer

65502

192.168.30.4 (metric 128) from 10.3.3.3 (10.3.3.3)

Origin IGP, metric 100, localpref 100, valid, internal, best

Schauen Sie auf das R2-Display:

r2# show ip bgp 10.4.0.1

BGP routing table entry for 10.4.0.0/16, version 10

Paths: (1 available, best #1, table Default-IP-Routing-Table)

Advertised to non peer-group peers:

10.1.1.1 10.3.3.3

65502

192.168.20.4 from 192.168.20.4 (10.4.4.4)

Origin IGP, metric 100, localpref 100, valid, external, best

r2# show ip bgp 10.5.0.1

BGP routing table entry for 10.5.0.0/16, version 11

Paths: (2 available, best #1, table Default-IP-Routing-Table)

Advertised to non peer-group peers:

192.168.20.4

65502

192.168.30.4 (metric 74) from 10.3.3.3 (10.3.3.3)

Origin IGP, metric 100, localpref 100, valid, internal, best

65502

192.168.20.4 from 192.168.20.4 (10.4.4.4)

Origin IGP, metric 200, localpref 100, valid, external

Der Grund, warum R2 nur einen Pfad für 10.4.0.0/16 anzeigt, liegt darin, dass R3 das Update für 10.4.0.0/16 zurückzieht (ein Update mit einer nicht erreichbaren Metrik sendet), sobald es bemerkt, dass R3 R2 verwendet, um auf 10.4.0.0/16 zuzugreifen (nachdem Sie BGP BestPath auf allen verfügbaren Pfaden ausgeführt haben):

r3# show ip bgp 10.4.0.0

BGP routing table entry for 10.4.0.0/16, version 20

Paths: (2 available, best #1, table Default-IP-Routing-Table)

Advertised to non peer-group peers:

192.168.30.4

65502

192.168.20.4 (metric 74) from 10.2.2.2 (10.2.2.2)

Origin IGP, metric 100, localpref 100, valid, internal, best

65502

192.168.30.4 from 192.168.30.4 (10.4.4.4)

Origin IGP, metric 200, localpref 100, valid, external

Dadurch kann R2 etwas Speicher speichern, da es diese nutzlosen Informationen nicht speichern muss. Falls die BGP-Sitzung zwischen R2 und R4 fehlschlägt, sendet R2 ein unerreichbares Update für 10.4.0.0/16 an R3. Dieses Update würde R3 veranlassen, ein Update mit der R3-Route für 10.4.0.0/16 über R4 an R2 zu senden. R2 könnte beginnen, über R3 zu routen.

Der Befehl bgp deterministic-med

Wenn Sie die  bgp deterministic-med    -Befehl entfernt es jede zeitliche Abhängigkeit von MED-basierten Best Path-Entscheidungen. Es stellt sicher, dass ein genauer MED-Vergleich über alle von demselben autonomen System (AS) empfangenen Routen hinweg durchgeführt wird.

Wenn Sie  bgp deterministic-med kann die Reihenfolge, in der Routen empfangen werden, MED-basierte Entscheidungen über den besten Pfad beeinflussen. Dies kann auftreten, wenn dieselbe Route von mehreren ASs oder Confederation Sub-ASs mit genau derselben Pfadlänge aber unterschiedlichen MEDs empfangen wird.

Beispiele

Betrachten Sie beispielsweise die folgenden Routen:

entry1: ASPATH 1, MED 100, internal, IGP metric to NEXT_HOP 10

entry2: ASPATH 2, MED 150, internal, IGP metric to NEXT_HOP 5

entry3: ASPATH 1, MED 200, external

Die Reihenfolge, in der die BGP-Routen empfangen wurden, ist entry3, entry2 und entry1 (entry3 ist der älteste Eintrag in der BGP-Tabelle und entry1 der neueste).

Ein BGP-Router mit deaktiviertem BGP-Determinist-med

Ein BGP-Router mit bgp deterministic-med disabled (Deaktiviert) wählt entry2 gegenüber entry1 aus, da eine niedrigere IGP-Metrik den NEXT_HOP erreicht (MED wurde in dieser Entscheidung nicht verwendet, da entry1 und entry2 von zwei verschiedenen ASs stammen). Es bevorzugt dann entry3 gegenüber entry2, da es extern ist. Eintrag3 hat jedoch eine höhere MED als Eintrag1. Weitere Informationen zu den BGP-Pfadauswahlkriterien finden Sie unter BGP Best Path Selection Algorithm .

BGP-Router mit aktivierter BGP-Deterministik-med

In diesem Fall werden Routen vom gleichen AS gruppiert, und die besten Einträge jeder Gruppe werden verglichen. Im vorliegenden Beispiel gibt es zwei AS, AS 1 und AS 2.

Group 1:  entry1: ASPATH 1, MED 100, internal, IGP metric to NEXT_HOP 10

entry3: ASPATH 1, MED 200, external

Group 2:  entry2: ASPATH 2, MED 150, internal, IGP metric to NEXT_HOP 5

In Gruppe 1 ist der beste Pfad entry1, da der untere MED-Wert verwendet wird (MED wird in dieser Entscheidung verwendet, da die Pfade vom gleichen AS stammen). In Gruppe 2 gibt es nur einen Eintrag (Eintrag2). Der beste Pfad wird dann mit einem Vergleich der Gewinner jeder Gruppe ermittelt (MED wird in diesem Vergleich standardmäßig nicht verwendet, da die Gewinner jeder Gruppe aus verschiedenen ASs stammen. Wenn Sie  bgp always-compare-med   Dadurch wird dieses Standardverhalten geändert). Wenn Sie jetzt Eintrag1 (Gewinner aus Gruppe 1) und Eintrag2 (Gewinner aus Gruppe 2) vergleichen, kann Eintrag2 der Gewinner sein, da er die bessere IGP-Metrik für den nächsten Hop aufweist.

Wenn bgp always-compare-med   wurde auch aktiviert, wenn Sie Eintrag 1 (der Gewinner aus Gruppe 1) und Eintrag 2 (der Gewinner aus Gruppe 2) vergleichen, kann Eintrag 1 aufgrund der niedrigeren MED der Gewinner sein.

Cisco empfiehlt die Aktivierung bgp always-compare-med  in allen neuen Netzwerkbereitstellungen. Wenn darüber hinaus  bgp always-compare-med  ist aktiviert, sind BGP MED-Entscheidungen immer deterministisch.

Weitere Informationen über die bgp deterministic-med und bgp always-compare-med  -Befehlen, siehe How the bgp deterministic-med Command Differers from the bgp always-compare-med Command.

Zugehörige Informationen

- Beispielkonfiguration für BGP mit zwei verschiedenen Service Providern (Multihoming)

- IP/BGP-Unterstützung

- BGP-Anwenderberichte

- Technischer Support und Downloads von Cisco