Gebruik MultiExit Discriminator om BGP Best Path Selection te beïnvloeden
Inleiding
Dit document beschrijft de bgp deterministisch-med opdracht en hoe deze de padselectie beïnvloedt op basis van de multiexit discriminator (MED).
Voorwaarden
Vereisten
Cisco raadt kennis van de volgende onderwerpen aan:
- Basis IP-routering
- Border Gateway Protocol (BGP)
Gebruikte componenten
Dit document is niet beperkt tot specifieke software- en hardware-versies.
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.
Conventies
Raadpleeg Cisco Technical Tips Conventions voor meer informatie over Cisco-documentatieconventies.
Het MED-attribuut
MED is een optioneel, niet-transitief BGP-attribuut dat een hint geeft aan externe buren over het voorkeurspad naar een autonoom systeem (AS) met meerdere toegangspunten. MED staat ook bekend als de externe metriek van een route en een lagere MED-waarde heeft de voorkeur boven een hogere waarde. Standaard vergelijkt BGP MED-waarden alleen tussen paden die zijn ontvangen van dezelfde aangrenzende AS.
Opmerking: standaard vergelijkt BGP MED-waarden alleen voor paden die zijn ontvangen van dezelfde aangrenzende AS, tenzij bgp always-compare-med is geconfigureerd. Zie Hoe de bgp deterministisch-med Command verschilt van de bgp always-compare-med Command voor aanvullende informatie.
Netwerktopologie
Netwerktopologie
Voorbeeld
In dit scenario is AS 65502 een gebruiker van de ISP die AS 65501 heeft. R4 is verbonden met twee verschillende routers aan de ISP-kant voor redundantiedoeleinden en adverteert twee netwerken met ISP-10.4.0.0/16 en 10.5.0.0/16. Een deel van de relevante configuratie wordt weergegeven in deze sectie.
| R4 |
|---|
! 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 |
|---|
! 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 |
De relevante R1- en R3-configuraties gebruiken hetzelfde ontwerp als R2. R1, R2 en R3 hebben iBGP bereikbaarheid via loopback-interfaces en de IGP biedt bereikbaarheid voor BGP next hops. R3 heeft een eBGP-sessie met R4- en iBGP-sessies met R1 en R2.
R1 heeft een iBGP die gelijkt op R2 en een op R3. Kijk naar wat de tabellen R1, R2 en R3 BGP weergeven voor de twee netwerken die door R4 worden geadverteerd:
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
Zowel R2 als R3 kiezen het beste pad als de externe route van R4, die wordt verwacht op basis van het BGP-algoritme voor de selectie van het beste pad. Raadpleeg de sectie BGP-algoritme voor selectie van het beste pad voor meer informatie.
Op dezelfde manier kiest R1 R2 om toegang te krijgen tot de twee netwerken, omdat de eerdere BGP-kenmerken voor het beste pad gelijklopen en de laagste BGP-router-ID wordt gebruikt als de koppelingsbreker. R2 heeft de router ID 10.2.2.2 en R3 heeft router ID 10.3.3.3. Omdat R2s router-ID 10.2.2.2 is en R3s router-ID 10.3.3.3, wordt R2 gekozen. In deze basisconfiguratie gaat al het verkeer naar de twee netwerken in AS 65502 standaard van R1 naar R2 en vervolgens naar R4. Stel nu dat R4 het verkeer dat het ontvangt van AS 65501 wil laden en balanceren. Om dit te doen zonder R4 ISP-wijzigingen, configureert u R4 om MED te gebruiken om verkeer voor het ene netwerk langs het ene pad te forceren en verkeer voor het andere netwerk langs het andere pad.
Opmerking: het beschreven MED-configuratievoorbeeld biedt een verkeerstechniek per prefix, geen echte werklastverdeling voor gelijke kosten.
Dit is de configuratie van R4 nadat u de vereiste configuratie hebt toegepast:
| R4 |
|---|
! 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 setMED-R3 is applying a MED of 200 to the 10.4.0.0/16 |
Opmerking: In dit voorbeeld worden alleen 10.4.0.0/16 en 10.5.0.0/16 geadverteerd. Als er extra voorvoegsels worden geadverteerd aan dezelfde buurman, voeg ze dan toe aan de juiste toegangslijst of routekaartvolgorde. Voeg een definitieve vergunningenreeks toe als er reclame moet worden gemaakt voor niet-overeenkomende voorvoegsels zonder dat deze worden gefilterd door de uitgaande routekaart.
Nadat MED is toegepast, selecteert R2 het R2-naar-R4 pad/link als beste voor 10.4.0.0/16, en R3 selecteert het R3-naar-R4 pad/link als beste voor 10.5.0.0/16. In de getoonde geconvergeerde toestand ontvangt R1 de in aanmerking komende beste iBGP-advertentie voor elk voorvoegsel en gebruikt R2 voor 10.4.0.0/16 en R3 voor 10.5.0.0/16:
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#show 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
Zie het volgende voorbeeld voor het R2-scherm:
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
R2 toont één pad voor 10.4.0.0/16 omdat R3 niet langer zijn R4-geleerde pad adverteert nadat R3 het iBGP-geleerde pad door R2 als beste selecteert. R3 trekt de update in (stuurt een BGP-routeintrekking, deze update bevat een onbereikbare statistiek) voor 10.4.0.0/16 zodra het merkt dat R3 R2 gebruikt om toegang te krijgen tot 10.4.0.0/16. Standaard iBGP-advertentieregels voorkomen dat R3 het door iBGP geleerde pad terug naar een andere iBGP-peer in deze topologie adverteert:
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
Hierdoor kan R2 wat geheugen opslaan, omdat het deze nutteloze informatie niet hoeft op te slaan. In het geval dat de BGP-sessie tussen R2 en R4 mislukt, zou R2 een onbereikbare update naar R3 sturen voor 10.4.0.0/16. Deze update zou R3 activeren om een update te verzenden met de R3-route voor 10.4.0.0/16 via R4 naar R2. R2 kan beginnen met de route via R3.
Het MED-commando
Om deterministische MED-vergelijking mogelijk te maken, configureert u de opdracht bgp deterministic-med onder de configuratiemodus BGP-router. Wanneer deze optie is ingeschakeld, verwijdert bgp deterministic-med temporele afhankelijkheid van MED-gebaseerde best-path beslissingen door paden van dezelfde AS te groeperen als voor vergelijking. Dit zorgt ervoor dat een nauwkeurige MED-vergelijking wordt gemaakt op alle routes die worden ontvangen van hetzelfde autonome systeem (AS).
Als u bgp deterministic-med uitschakelt, kunnen de bestelroutes die worden ontvangen invloed hebben op op MED gebaseerde beste padbeslissingen. Dit kan gebeuren wanneer dezelfde route wordt ontvangen van meerdere AS's of subAS's van de confederatie, met precies dezelfde padlengte, maar verschillende MED's.
Voorbeelden
Denk bijvoorbeeld aan de volgende routes:
| inzending | AS-pad | MED | lokale voorkeur | AS-padlengte | oorsprong |
|---|---|---|---|---|---|
| vermelding1 |
AS 65001 |
100 |
100 |
1 |
ZGP |
| ingang2 |
AS 65002 |
50 |
100 |
1 |
ZGP |
| vermelding3 |
AS 65001 |
20 |
100 |
1 |
ZGP |
Een BGP Router met MED Uitgeschakeld
Aankomstorder 1 voorbeeld
De volgorde waarin BGP-routes werden ontvangen is (entry1 is de oudste vermelding in de BGP-tabel en entry3 is de nieuwste):
- vermelding1
- ingang2
- vermelding3
Aanvankelijk bestaat er maar één route, dus entry1 wordt het beste pad. Wanneer entry2 van AS65002 wordt vergeleken met entry1 van AS65001, wordt MED genegeerd omdat de routes afkomstig zijn van verschillende aangrenzende AS's; aangezien alle resterende attributen gelijk zijn, behoudt de router het huidige beste pad, entry1.
Wanneer vermelding 3 van AS65001 met MED 20 wordt vergeleken met vermelding 1 van AS65001 met MED 100, wordt MED geëvalueerd omdat beide routes afkomstig zijn van dezelfde naburige AS. Aangezien 20 lager is dan 100, wordt entry3 het laatste beste pad.
Voorbeeld van aankomstorder 2
Stel nu dat dezelfde routes in een andere volgorde aankomen:
- ingang2
- vermelding3
- vermelding1
In eerste instantie wordt entry2 geselecteerd als het beste pad. Wanneer entry3 van AS65001 wordt vergeleken met entry2 van AS65002, wordt MED niet geëvalueerd omdat de routes afkomstig zijn van verschillende aangrenzende AS's; aangezien alle resterende attributen gelijk zijn, behoudt de router het huidige beste pad, entry2.
Wanneer vermelding 1 van AS65001 wordt vergeleken met vermelding 2 van AS65002, wordt MED opnieuw genegeerd omdat de routes afkomstig zijn van verschillende aangrenzende AS's. Als gevolg hiervan houdt de router entry2 als het laatste beste pad.
Met MED uitgeschakeld, beïnvloedt de route-aankomstvolgorde de vergelijkingsvolgorde. Merk op dat de ontvangen router precies dezelfde drie routes is, maar het heeft verschillende beste paden geselecteerd omdat de routes in een andere volgorde zijn aangekomen. Dit is de tijdelijke afhankelijkheid die bgp deterministisch-med is ontworpen om te elimineren.
Opmerking: Raadpleeg het BGP Best Path Selection Algorithm voor meer informatie over BGP-padselectiecriteria.
Een BGP-router met MED ingeschakeld
Met MED ingeschakeld, groepeert de router eerst routes door naburige AS voordat hij op MED gebaseerde beslissingen neemt. In dit geval worden routes van hetzelfde AS gegroepeerd en worden de beste vermeldingen van elke groep vergeleken. In het gegeven voorbeeld zijn er twee AS's, AS 65001 en AS 65002.
| Groep | AS-pad | inzending | Geselecteerde route | reden |
|---|---|---|---|---|
| Groep 1 |
AS 65001 |
vermelding 1 (MED 100), vermelding 3 (MED 20) |
vermelding3 |
Lagere MED (20 < 100) |
| Groep 2 |
AS 65002 |
entry2 (MED 50) |
ingang2 |
Alleen kandidaat |
In groep 1 is het beste pad entry3 vanwege de lagere MED (MED wordt in dit besluit gebruikt omdat de paden van dezelfde AS zijn). In groep 2 is er slechts één vermelding (entry2). Het beste pad wordt dan bepaald met een vergelijking van de winnaars van elke groep, MED wordt in deze vergelijking standaard niet gebruikt omdat de winnaars van elke groep van verschillende AS's zijn.
Op dit moment wordt MED niet meer in aanmerking genomen, omdat de resterende routes afkomstig zijn van verschillende aangrenzende AS's. Het BGP best-path algoritme gaat verder met de volgende attributen (zoals eBGP vs. iBGP, IGP metriek naar de volgende hop, oudste pad, router-ID, enzovoort, afhankelijk van welke attributen verschillen).
Het belangrijkste voordeel is dat dit proces onafhankelijk is van de routes die zijn ontvangen. Of de router de routes leert als:
- Inschrijving1 → Inschrijving2 → Inschrijving3
- Entry2 → Entry3 → Entry1
- Toevoeging3 → Toevoeging1 → Toevoeging2
Als gevolg hiervan leveren de aankomstbestellingen dezelfde uitkomst op, omdat de beslissing is gebaseerd op de routekenmerken in plaats van de volgorde waarin de updates zijn ontvangen.
Opmerking: Als bgp always-compare-med ook was ingeschakeld wanneer u entry3 (de winnaar uit groep 1) en entry 2 (de winnaar uit groep 2) vergelijkt; entry 3 is de winnaar vanwege lagere MED.
Opmerking: als u de opdracht bgp deterministic-med inschakelt, wordt de MED-variabele vergeleken bij het kiezen van routes die door verschillende leeftijdsgenoten in dezelfde AS worden geadverteerd. Door het bgp always-compare-med commando in te schakelen, wordt de MED vergeleken voor paden van buren in verschillende AS.
In dit voorbeeld wordt ervan uitgegaan dat alle BGP-kenmerken met een hogere prioriteit (zoals Gewicht, Lokale voorkeur, AS-padlengte, Oorsprong en andere) identiek zijn. Het doel is om het effect van MED te isoleren en te illustreren waarom het uitschakelen van bgp deterministic-med ervoor kan zorgen dat de beslissing over het beste pad afhankelijk is van de route-aankomstvolgorde.
Cisco raadt u aan bgp always-compare-med in te schakelen in alle nieuwe netwerkimplementaties. Bovendien, als bgp always-compare-med is ingeschakeld, zijn BGP MED-beslissingen altijd deterministisch.
Voor meer informatie over de bgp deterministisch-med en de bgp always-compare-med opdrachten, zie Hoe de bgp deterministisch-med Command verschilt van de bgp always-compare-med Command.
Gerelateerde informatie
- Voorbeeldconfiguratie voor BGP met twee verschillende serviceproviders (multihoming)
- IP/BGP-ondersteuning
- Casestudy’s van BGP
- Cisco Technical Support en downloads
Revisiegeschiedenis
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
3.0 |
30-Jul-2026
|
Bijgewerkte titel, inleiding, spelling, grammatica, horizontale regels invoegen om secties/leesbaarheid te scheiden. |
2.0 |
26-Jan-2024
|
Bijgewerkte SEO en formattering. |
1.0 |
10-Dec-2001
|
Eerste vrijgave |
Feedback