Informazioni sull'attributo BGP MED

Opzioni per il download

  • PDF     (257.8 KB)
    Visualizza con Adobe Reader su diversi dispositivi
  • ePub     (81.0 KB)
    Visualizza in diverse app su iPhone, iPad, Android, Sony Reader o Windows Phone
  • Mobi (Kindle)     (67.7 KB)
    Visualizza su dispositivo Kindle o tramite app Kindle su più dispositivi
Aggiornato:20 dicembre 2023
ID documento:217973

Linguaggio senza pregiudizi

La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.

Informazioni su questa traduzione

Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).

    Introduzione

    Questo documento descrive l'attributo MED Border Gateway Protocol (BGP) quando attraversa un limite ASA tramite implementazione in scenari diversi.

    Prerequisiti

    Requisiti

    Cisco raccomanda la conoscenza base di BGP.

    Componenti usati

    Il documento può essere consultato per tutte le versioni software o hardware. Gli scenari discussi in questo documento utilizzano le seguenti versioni hardware e software:

    • Scenario 1: router Cisco 2600 con software Cisco IOS® versione 12.4 o successive

    • Scenario 2: router Cisco 2600 con software Cisco IOS® versione 12.4 o successive

    Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

    Convenzioni

    Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

    Premesse

    Il Discriminatore Multi Exit (MED) fornisce un modo dinamico per influenzare un altro sistema autonomo (AS) nel modo di raggiungere una determinata rotta quando ci sono più punti di ingresso per quel AS. BGP utilizza una procedura sistematica per la scelta del percorso migliore. Prima di considerare l'attributo MED, è necessario considerare altri attributi importanti, ad esempio il peso, la preferenza locale, la route di origine e il percorso AS. Pertanto, se uno di questi criteri corrisponde, l'attributo MED non viene considerato.

    note-icon

    Nota: quando tutti gli altri fattori sono uguali, viene preferito il punto di uscita con il valore MED più basso.

    Case study

    Scenario 1

    Quando un altoparlante BGP apprende una route da un peer, la route MED viene passata ad altri peer BGP (iBGP) interni, ma non ai peer BGP (eBGP) esterni.

    Il router R1 e il router R2 vengono considerati nella stessa AS, ad esempio AS#100, e il router R3 appartiene a AS#101. Per semplificare le convenzioni, vengono utilizzati gli indirizzi IP nel blocco /24.

    I router R1 e R2 sono configurati come segue:

    Router 1 
    (Config)#interface Loopback10
(Config-if)#ip address xx.xx.xx.xx xxx.xxx.xxx.xxx
(Config-if)#interface FastEthernet0/0
(Config-if)#ip address xx.xx.xx.xx xxx.xxx.xxx.xxx
(Config)#router bgp 100
(Config-router)#no synchronization
(Config-router)#bgp router-id xx.xx.xx.xx
(Config-router)#bgp log-neighbor-changes
(Config-router)#network xx.xx.xx.xx mask xxx.xxx.xxx.xxx route-map ATTACH_MED
(Config-router)#neighbor xxx.x.xx.x remote-as xxx
(Config-router)#no auto-summary
(Config)#access-list 10 permit xx.xx.xx.xx
(Config)#route-map ATTACH_MED permit xx
(Config)#match ip address xx
(Config)#set metric xxx
    Router 2 
    (Config)#interface FastEthernet0/0
(Config-if)#ip address xxx.x.xx.x xxx.xxx.xxx.x
(Config-if)#interface Serial1/0
(Config-if)#ip address xxx.x.xx.x xxx.xxx.xxx.x
(Config-if)#encapsulation frame-relay IETF
(Config-if)#no fair-queue
(Config-if)#frame-relay map ip xxx.x.xx.x 203 broadcast
(Config-if)#no frame-relay inverse-arp
(Config-if)#frame-relay lmi-type ansi
(Config)#router bgp 100
(Config-router)#no synchronization
(Config-router)#bgp router-id xx.xx.xx.xx
(Config-router)#bgp log-neighbor-changes
(Config-router)#neighbor xxx.x.xx.x remote-as 100
(Config-router)#neighbor xxx.x.xx.x remote-as 101
(Config-router)#neighbor xxx.x.xx.x ebgp-multihop 3
(Config-router)#no auto-summary

    La configurazione del router R3 è mostrata qui:

    Router 3 
    (Config)#interface Serial1/0
(Config-if)#ip address xxx.x.xx.x xxx.xxx.xxx.x
(Config-if)#encapsulation frame-relay IETF
(Config-if)#no fair-queue
(Config-if)#frame-relay map ip xxx.x.xx.x 302 broadcast
(Config-if)#no frame-relay inverse-arp
(Config-if)#frame-relay lmi-type ansi
(Config)#router bgp 101
(Config-router)#no synchronization
(Config-router)#bgp log-neighbor-changes
(Config-router)#neighbor xxx.x.xx.x remote-as 100
(Config-router)#neighbor xxx.x.xx.x ebgp-multihop 3
(Config-router)#no auto-summary

    In questa configurazione, R1 e R2 eseguono iBGP. Pertanto, quando un aggiornamento inserisce l'AS con una determinata metrica, tale metrica viene utilizzata per prendere decisioni all'interno dell'AS.

    Il comando show ip bgp, se verificato da R2, visualizza il valore della metrica per xx.xx.xx.xx, derivato dal router iBGP adiacente xxx.x.xx.x e con un valore MED di 100.

    eBGP è in esecuzione tra R2 e R3 perché si trovano in un'appliance ASA diversa. Quando lo stesso aggiornamento passa a un terzo AS, ad esempio AS#101, la metrica viene restituita a 0.

    La metrica del comando show ip bgp, quando selezionato da R3, viene rimossa perché xx.xx.xx.xx attraversa il limite AS (101).

    Da questo scenario, è evidente che l'attributo MED può influenzare il traffico in entrata dai sistemi autonomi adiacenti.

    L'attributo MED non può influenzare le decisioni di instradamento di sistemi autonomi più remoti. Quando un altoparlante BGP apprende una route da un peer, può passare il MED della route a qualsiasi peer iBGP, ma non ai peer eBGP.

    Di conseguenza, il MED ha rilevanza solo tra sistemi autonomi vicini.

    Scenario 2

    Se la route iniettata nel BGP (tramite il comando networkorredistributecommand) proviene da un IGP (RIP o EIGRP o OSPF), il MED viene derivato dalla metrica IGP e la route viene annunciata a un router adiacente eBGP con questo MED.

    In questa rete, R1 è configurato per l'esecuzione in una rete RIP. I router R2 e R3 eseguono BGP, dove R2 è configurato con AS 100 mentre R3 è configurato con AS 101.

    Il router R1 è configurato qui:

    Router R1 
    (Config)#interface Loopback10
(Config-if)#ip address xx.xx.xx.xx xxx.xxx.xxx.xxx
(Config-if)#interface FastEthernet0/0
(Config-if)#ip address xxx.x.xx.x xxx.xxx.xxx.x
(Config)#router rip
(Config-router)#network xx.x.x.x
(Config-router)#network xxx.x.xx.x
(Config-router)#no auto-summary

    I router R2 e R3 sono configurati per BGP, dove la ridistribuzione viene eseguita in R2 per inserire le reti RIP in un BGP.

    Router R2 
    (Config)#interface FastEthernet0/0
(Config-if)#ip address xxx.x.xx.x xxx.xxx.xxx.x
(Config-if)#interface Serial1/0
(Config-if)#ip address xxx.x.xx.x xxx.xxx.xxx.x
(Config-if)#encapsulation frame-relay IETF
(Config-if)#no fair-queue
(Config-if)#frame-relay map ip xxx.x.xx.x 203 broadcast
(Config-if)#no frame-relay inverse-arp
(Config-if)#frame-relay lmi-type ansi
(Config)#router rip
(Config-router)# network xxx.x.xx.x
(Config-router)#no auto-summary
(Config-router)#router bgp 100
(Config-router)#no synchronization
(Config-router)#bgp router-id xx.xx.xx.xx
(Config-router)#bgp log-neighbor-changes
(Config-router)#neighbor xxx.x.xx.x remote-as 101
(Config-router)#neighbor xxx.x.xx.x ebgp-multihop 3
(Config-router)#redistribute rip metric 1
 Config-router)#no auto-summary
    Router R3 
    (Config)#interface Serial1/0
(Config-if)#ip address xxx.x.xx.x xxx.xxx.xxx.x
(Config-if)#encapsulation frame-relay IETF
(Config-if)#no fair-queue
(Config-if)#frame-relay map ip xxx.x.xx.x 302 broadcast
(Config-if)#no frame-relay inverse-arp
(Config-if)#frame-relay lmi-type ansi
(Config)#router bgp 101
(Config-router)# no synchronization
(Config-router)#bgp router-id xx.xx.xx.xx
(Config-router)#bgp log-neighbor-changes
(Config-router)#neighbor xxx.x.xx.x remote-as 100
(Config-router)#neighbor xxx.x.xx.x ebgp-multihop 3
(Config-router)#no auto-summary

    RIP e BGP eseguiti su R2. Se si controlla con show ip bgp il comando, si osserverà che il prefisso rete x.x.x.x viene visualizzato con una metrica di 1, derivata dal RIP.

    Tuttavia, in R3 che funziona su eBGP, la rete viene pubblicizzata prendendo in considerazione il valore MED derivato dall'IGP. In questo caso si tratta di RIP. Il prefisso 10.0.0.0 viene annunciato con il valore IGP MED, che è la metrica 1 di RIP. Questa condizione è illustrata in questo output.

    In questo scenario, il comportamento di MED, nel caso in cui le reti vengano iniettate nel router BGP tramite il comando networkorredistributecommand, viene mostrato dove il valore MED effettivo viene sostituito con quello della metrica IGP.

    Poiché questo attributo è un suggerimento per i vicini esterni sulla preferenza del percorso in un AS, come indicato in precedenza, non sempre viene preso in considerazione se ci sono altri attributi più importanti per determinare la via migliore.

    Per ottenere lo stesso effetto con un attributo più deterministico, utilizzare set as-path prepend il comando nella mappa route.

    Se si antepone il percorso AS per determinate route, il percorso continua a essere visualizzato da un'altra CA. Per ulteriori informazioni sull'utilizzo della funzione prepend di tipo AS-path, consultare il documento sull'utilizzo del comando set-aspath prepend.

    Informazioni correlate

    Cronologia delle revisioni

    Revisione Data di pubblicazione Commenti
    2.0
    20-Dec-2023
    Sono state aggiunte informazioni di base. Introduzione, traduzione automatica e formattazione aggiornate.
    1.0
    19-Jul-2022
    Versione iniziale
    TAC Authored

    Contributo dei tecnici Cisco

    • Tecnici Cisco TAC

    Questo documento ti è stato utile?

    FeedbackFeedback

    Contattaci