Sommario

Introduzione

1. È necessaria una route statica per le opzioni VPN tra MPLS e MPLS B e C

2. Mantenere gli obiettivi dei cicli di lavorazione sugli ASBR per l'opzione B di Inter-AS

3. Gli indirizzi Unicast con etichetta IPv4 non vengono annunciati da ASBR

4. È necessario un router adiacente fittizio iBGP per eBGP-eBGP (back-to-back eBGP) Vpnv4

5. Inter-AS Option C - L'etichetta BGP è preferita all'etichetta LDP

6. Opzione B tra appliance ASA - L'etichetta BGP è preferita all'etichetta LDP

7. Sessione BGP multihop su VPN (o 6PE o EVPN) Underlay

8. Ridistribuzione di BGP in LDP

9. Comando MPLS Activate Interface

Esempio 1. IGP ma non LDP

Esempio 2. Confederazione

Introduzione

Questo documento descrive alcuni scenari con un comportamento e una configurazione speciali per la combinazione di Multiprotocol Label Switching (MPLS) e Border Gateway Protocol (BGP) in Cisco IOS®-XR.

1. È necessaria una route statica per le opzioni VPN tra MPLS e MPLS B e C

In questa immagine viene illustrata l'impostazione dell'opzione B Inter-AS.

Immagine 1.

Il router PE1 di Provider Edge dispone di un percorso per il prefisso VRF 10.200.1.2/32, ma non è stato risolto.

RP/0/0/CPU0:PE1#show cef vrf one 10.200.1.2

10.200.1.2/32, version 3, internal 0x5000001 0x0 (ptr 0xa140be74) [1], 0x0 (0x0), 0x208 (0xa14a7118)

Updated Apr  7 14:36:45.628

Prefix Len 32, traffic index 0, precedence n/a, priority 3

via 10.3.1.4/32, 0 dependencies, recursive [flags 0x6000]

path-idx 0 NHID 0x0 [0xa0d87468 0x0]

recursion-via-/32

next hop VRF - 'default', table - 0xe0000000

unresolved

labels imposed {24004}

PE1 non dispone di una route per 10.3.1.4/32. Dispone di una route per 10.3.1.0/24.

RP/0/0/CPU0:PE1#show route 10.3.1.4

Routing entry for 10.3.1.0/24

Known via "ospf 1", distance 110, metric 3, type intra area

Installed Apr  7 14:07:01.140 for 00:32:48

Routing Descriptor Blocks

10.1.1.2, from 10.100.1.3, via GigabitEthernet0/0/0/0

Route metric is 3

No advertising protos.

È necessario che sia presente un percorso statico sull'ASBR (Autonomous System Border Route) per l'hop successivo. È necessario configurare questa route statica su ciascuna ASBR e ridistribuirla nel protocollo IGP (Interior Gateway Protocol).

router static

address-family ipv4 unicast

10.3.1.4/32 GigabitEthernet0/0/0/1

!

!

router ospf 1

redistribute static

Il percorso è stato risolto.

RP/0/0/CPU0:PE1#show cef vrf one 10.200.1.2

10.200.1.2/32, version 3, internal 0x5000001 0x0 (ptr 0xa140be74) [1], 0x0 (0x0), 0x208 (0xa14a7118)

Updated Apr  7 14:36:45.628

Prefix Len 32, traffic index 0, precedence n/a, priority 3

via 10.3.1.4/32, 3 dependencies, recursive [flags 0x6000]

path-idx 0 NHID 0x0 [0xa150f9f4 0x0]

recursion-via-/32

next hop VRF - 'default', table - 0xe0000000

next hop 10.3.1.4/32 via 24005/0/21

next hop 10.1.1.2/32 Gi0/0/0/0    labels imposed {24003 24004}

ASBR1 installa un'etichetta in uscita di POP verso ASBR2 per i prefissi VPNv4/6:

RP/0/0/CPU0:ASBR1#show mpls forwarding prefix 10.3.1.4/32

Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes

Label  Label       or ID              Interface                    Switched

------ ----------- ------------------ ------------ --------------- ------------

24005  Pop         10.3.1.4/32        Gi0/0/0/1    10.3.1.4        2506

Anche con l'hop successivo sul router ASBR verso i router adiacenti iBGP, l'inoltro delle etichette tra le appliance ASBR verrà interrotto, se il percorso statico non è configurato sull'appliance ASBR.

Con l'auto-hop successivo su ASBR1 verso PE1 e senza route statica:

RP/0/0/CPU0:ASBR1#show mpls forwarding labels 24006 detail

Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes

Label  Label       or ID              Interface                    Switched

------ ----------- ------------------ ------------ --------------- ------------

24006  24004       2:2:10.200.1.2/32               10.3.1.4        0

Updated: Apr  7 14:49:58.190

Path Flags: 0x6000 [  ]

Label Stack (Top -> Bottom): { }

MAC/Encaps: 0/0, MTU: 0

Packets Switched: 0

Nella colonna Interfaccia in uscita manca l'interfaccia in uscita. La route statica è richiesta sulle appliance ASBR per le opzioni B e C di Inter-AS.

2. Mantenere gli obiettivi dei cicli di lavorazione sugli ASBR per l'opzione B di Inter-AS

È necessario un comando per garantire che l'ASBR archivi/mantenga le route vpnv4/6 e le annunci. Senza questo comando, l'ASBR non memorizza le route se sull'ASBR non è configurato alcun VRF locale che importa una delle Route-Targets delle route o se non è un reflector di route (RR) per la famiglia di indirizzi vpnv4/6.

router bgp 1

address-family ipv4 unicast

!

address-family vpnv4 unicast

retain route-target all

!

3. Gli indirizzi Unicast con etichetta IPv4 non vengono annunciati da ASBR

Il protocollo IPv4 unicast con etichetta è richiesto nelle reti Inter-AS Option C o Seamless MPLS (Unified MPLS). Infatti, a differenza dei prefissi IPv4 (IPv6), i prefissi vpnv4/6 sono etichettati per impostazione predefinita. In caso contrario, il percorso end-to-end Label Switched (LSP) viene interrotto e il flusso del traffico end-to-end non riesce.

Nell'immagine 2 è illustrata l'impostazione dell'opzione C Inter-AS.

Immagine 2.

I router P1 e P2 sono anche i Route Reflector nel loro sistema autonomo (AS) per vpnv4.

L'opzione LU (Labeled Unicast) viene utilizzata per trasportare i prefissi di loopback da un AS all'altro.

ASBR1 ha questa famiglia di indirizzi configurata, ma non contiene route:

RP/0/0/CPU0:ASBR1#show bgp ipv4 labeled-unicast

RP/0/0/CPU0:ASBR1#

RP/0/0/CPU0:ASBR1#show bgp ipv4 labeled-unicast summary

BGP router identifier 10.100.1.3, local AS number 1

BGP generic scan interval 60 secs

Non-stop routing is enabled

BGP table state: Active

Table ID: 0xe0000000   RD version: 41

BGP main routing table version 41

BGP NSR Initial initsync version 2 (Reached)

BGP NSR/ISSU Sync-Group versions 0/0

BGP scan interval 60 secs

BGP is operating in STANDALONE mode.

Process       RcvTblVer   bRIB/RIB   LabelVer  ImportVer  SendTblVer  StandbyVer

Speaker              41         41         41         41          41           0

Neighbor        Spk    AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down  St/PfxRcd

10.3.1.4          0     2     150     151       41    0    0 00:06:29          0

10.100.1.2        0     1      52      52       41    0    0 00:06:42          0

Il motivo è che l'ASBR deve disporre del comando seguente in modo da poter allocare un'etichetta Multi-Protocol Label Switching (MPLS) per ciascuna route e quindi annunciare le route.

RP/0/0/CPU0:ASBR1#show run router bgp

router bgp 1

address-family ipv4 unicast

redistribute ospf 1

allocate-label all

!

Nota: Il comando può allocare etichette a prefissi specifici se è specificato un criterio di route.

Il risultato di questo comando è:

RP/0/0/CPU0:ASBR1#show bgp ipv4 labeled-unicast

BGP router identifier 10.100.1.3, local AS number 1

BGP generic scan interval 60 secs

Non-stop routing is enabled

BGP table state: Active

Table ID: 0xe0000000   RD version: 52

BGP main routing table version 52

BGP NSR Initial initsync version 2 (Reached)

BGP NSR/ISSU Sync-Group versions 0/0

BGP scan interval 60 secs

Status codes: s suppressed, d damped, h history, * valid, > best

i - internal, r RIB-failure, S stale, N Nexthop-discard

Origin codes: i - IGP, e - EGP, ? - incomplete

Network            Next Hop            Metric LocPrf Weight Path

*> 10.1.1.0/24        10.1.2.2                 2         32768 ?

*> 10.1.2.0/24        0.0.0.0                  0         32768 ?

*> 10.2.1.0/24        10.3.1.4                 0             0 2 ?

*> 10.2.2.0/24        10.3.1.4                 2             0 2 ?

*> 10.3.1.0/24        0.0.0.0                  0         32768 ?

*                     10.3.1.4                 0             0 2 ?

*> 10.100.1.1/32      10.1.2.2                 3         32768 ?

*> 10.100.1.2/32      10.1.2.2                 2         32768 ?

*> 10.100.1.3/32      0.0.0.0                  0         32768 ?

*> 10.100.1.4/32      10.3.1.4                 0             0 2 ?

*> 10.100.1.5/32      10.3.1.4                 2             0 2 ?

*> 10.100.1.6/32      10.3.1.4                 3             0 2 ?

Processed 11 prefixes, 12 paths

RP/0/0/CPU0:ASBR1#show bgp ipv4 labeled-unicast 10.100.1.6/32

BGP routing table entry for 10.100.1.6/32

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                 48          48

Local Label: 24008

Last Modified: Apr  7 16:20:04.509 for 00:00:49

Paths: (1 available, best #1)

Advertised to peers (in unique update groups):

10.100.1.2

Path #1: Received by speaker 0

Advertised to peers (in unique update groups):

10.100.1.2

2

10.3.1.4 from 10.3.1.4 (10.100.1.4)

Received Label 24002

Origin incomplete, metric 3, localpref 100, valid, external, best, group-best

Received Path ID 0, Local Path ID 1, version 48

Origin-AS validity: not-found

In breve:

- È necessario configurare l'allocazione delle etichette (su tutti i router ASBR e PE)

- È necessario configurare la famiglia di indirizzi ipv4 con etichetta unicast per il sistema adiacente BGP

4. È necessario un router adiacente fittizio iBGP per eBGP-eBGP (back-to-back eBGP) Vpnv4

Guardate l'immagine 3.

Immagine 3.

Ci sono tre ASBR di fila. L'ASBR3 esegue eBGP vpnv4 unicast su ASBR1 e ASBR2.

Nota: È necessario configurare le route statiche anche su ASBR3.

RP/0/0/CPU0:ASBR3#show bgp vpnv4 unicast

BGP router identifier 10.100.1.7, local AS number 3

BGP generic scan interval 60 secs

Non-stop routing is enabled

BGP table state: Active

Table ID: 0x0   RD version: 0

BGP main routing table version 3

BGP NSR Initial initsync version 2 (Reached)

BGP NSR/ISSU Sync-Group versions 0/0

BGP scan interval 60 secs

Status codes: s suppressed, d damped, h history, * valid, > best

i - internal, r RIB-failure, S stale, N Nexthop-discard

Origin codes: i - IGP, e - EGP, ? - incomplete

Network            Next Hop            Metric LocPrf Weight Path

Route Distinguisher: 1:1

*> 10.200.1.1/32      10.4.1.3                               0 1 ?

Route Distinguisher: 2:2

*> 10.200.1.2/32      10.4.2.4                               0 2 ?

Processed 2 prefixes, 2 paths

RP/0/0/CPU0:ASBR3#show bgp vpnv4 unicast rd 1:1 10.200.1.1/32

BGP routing table entry for 10.200.1.1/32, Route Distinguisher: 1:1

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                  2           2

Last Modified: Apr  7 18:45:21.510 for 00:03:30

Paths: (1 available, best #1)

Not advertised to any peer

Path #1: Received by speaker 0

Not advertised to any peer

1

10.4.1.3 from 10.4.1.3 (10.100.1.3)

Received Label 24009

Origin incomplete, localpref 100, valid, external, best, group-best, import-candidate, not-in-vrf

Received Path ID 0, Local Path ID 1, version 2

Extended community: RT:1:1

C'è un problema con la pubblicità delle route vpnv4 da ASBR3: ASBR3 non annuncia le route vpnv4 esterne in uscita.

La soluzione consiste nel configurare un router adiacente iBGP fittizio su ASBR3 e abilitare l'opzione next-hop-self: Non è necessario che il vicino iBGP fittizio sia attivo.

router bgp 3

address-family vpnv4 unicast

retain route-target all

!

neighbor 10.4.1.3

remote-as 1  address-family vpnv4 unicast

route-policy PASS in

route-policy PASS out

!

!

neighbor 10.4.2.4

remote-as 2

address-family vpnv4 unicast

route-policy PASS in

route-policy PASS out

!

!

neighbor 10.99.99.99

remote-as 3

description dummy-iBGP neighbor for back-to-back eBGP vpnv4

update-source Loopback0

address-family vpnv4 unicast

next-hop-self

!

!

!

Di conseguenza, la route vpnv4 viene ora annunciata:

RP/0/0/CPU0:ASBR3#show bgp vpnv4 unicast rd 1:1 10.200.1.1/32

BGP routing table entry for 10.200.1.1/32, Route Distinguisher: 1:1

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                 12          12

Local Label: 24002

Last Modified: Apr  7 18:58:04.510 for 00:01:46

Paths: (1 available, best #1)

Advertised to update-groups (with more than one peer):

0.2

Path #1: Received by speaker 0

Advertised to update-groups (with more than one peer):

0.2

1

10.4.1.3 from 10.4.1.3 (10.100.1.3)

Received Label 24009

Origin incomplete, localpref 100, valid, external, best, group-best, import-candidate, not-in-vrf

Received Path ID 0, Local Path ID 1, version 12

Extended community: RT:1:1

5. Inter-AS Option C - L'etichetta BGP è preferita all'etichetta LDP

Per una configurazione con due ASBR collegate su più collegamenti, fare riferimento a questa immagine. Per far funzionare questo problema, la sessione LU ipv4 di eBGP tra le ASBR deve essere multi-hop perché ci sono collegamenti paralleli tra di esse.

Immagine 4.

Questa è l'opzione C di Inter-AS. I router P1 e P2 sono anche i Route-Reflector per vpnv4.

Tra i router PE e gli ASBR è presente un unicast con etichetta IPv4. Gli ASBR sono collegati direttamente su più collegamenti.

Sull'ASBR è possibile visualizzare:

router bgp 1

…

neighbor 10.100.1.4

remote-as 2

ebgp-multihop 2

update-source Loopback0

address-family ipv4 labeled-unicast

route-policy PASS in

route-policy PASS out

Non è necessario un LDP (Label Distribution Protocol) tra le appliance ASBR. BGP si occuperà dell'inoltro MPLS sui collegamenti tra gli ASBR.

RP/0/0/CPU0:ASBR1#show mpls interfaces

Interface                  LDP      Tunnel   Static   Enabled

-------------------------- -------- -------- -------- --------

GigabitEthernet0/0/0/0     Yes      No       No       Yes

GigabitEthernet0/0/0/1     No       No       No       Yes

GigabitEthernet0/0/0/2     No       No       No       Yes

GigabitEthernet0/0/0/3     No       No       No       Yes

GigabitEthernet0/0/0/4     No       No       No       Yes

Finora tutto bene. Il problema è relativo allo scenario illustrato in questa immagine.

Immagine 5.

Questa è l'opzione C di Inter-AS. I router P1 e P2 sono anche i Route-Reflector per vpnv4.

Tra i router PE e gli ASBR è presente un unicast con etichetta IPv4. ASBR1 e ASBR2 non sono collegati direttamente. Sono connessi in multi-hop, attraverso una rete che esegue un IGP e un LDP. Nell'immagine 5, questa rete intermedia è rappresentata dal router ASBR3, che esegue un IGP e un LDP con ASBR1 e ASBR2.

Con il multi-hop eBGP sugli ASBR, c'è un problema. La sessione BGP tra le RR in ciascun ASA non viene nemmeno visualizzata.

RP/0/0/CPU0:P1#show cef 10.100.1.5

10.100.1.5/32, version 263, internal 0x1000001 0x0 (ptr 0xa13bde74) [1], 0x0 (0xa1389560), 0xa28 (0xa14a72a8)

Updated Apr  8 09:38:02.551

local adjacency 10.1.2.3

Prefix Len 32, traffic index 0, precedence n/a, priority 3

via 10.1.2.3/32, GigabitEthernet0/0/0/1, 5 dependencies, weight 0, class 0 [flags 0x0]

path-idx 0 NHID 0x0 [0xa0e8b2a4 0x0]

next hop 10.1.2.3/32

local adjacency

local label 24004      labels imposed {24007}

Per passare da P1, RR in AS 1 a P2, RR in AS 2, l'etichetta in uscita è 24007. Su ASBR1, questa etichetta viene sostituita con l'etichetta 24000.

RP/0/0/CPU0:ASBR1#show mpls forwarding labels 24007

Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes

Label  Label       or ID              Interface                    Switched

------ ----------- ------------------ ------------ --------------- ------------

24007  24000       10.100.1.5/32                   10.100.1.4      1404

RP/0/0/CPU0:ASBR1#show cef 10.100.1.5

10.100.1.5/32, version 155, internal 0x5000001 0x0 (ptr 0xa13be174) [1], 0x0 (0xa138965c), 0xa08 (0xa14a72d0)

Updated Apr  8 10:02:38.101

Prefix Len 32, traffic index 0, precedence n/a, priority 4

via 10.100.1.4/32, 5 dependencies, recursive, bgp-ext [flags 0x6020]

path-idx 0 NHID 0x0 [0xa150f874 0x0]

recursion-via-/32

next hop 10.100.1.4/32 via 24004/0/21

local label 24007

next hop 10.4.1.7/32 Gi0/0/0/4    labels imposed {ImplNull 24000}

L'etichetta 24000 è l'etichetta ricevuta su ASBR1 da BGP LU da ASBR2.

RP/0/0/CPU0:ASBR1#show bgp ipv4 labeled-unicast 10.100.1.5

BGP routing table entry for 10.100.1.5/32

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                 76          76

Local Label: 24007

Last Modified: Apr  8 09:37:57.509 for 00:04:05

Paths: (1 available, best #1)

Advertised to update-groups (with more than one peer):

0.3

Advertised to peers (in unique update groups):

10.100.1.1      10.100.1.2

Path #1: Received by speaker 0

Advertised to update-groups (with more than one peer):

0.3

Advertised to peers (in unique update groups):

10.100.1.1      10.100.1.2

2

10.100.1.4 from 10.100.1.4 (10.100.1.4)

Received Label 24000

Origin incomplete, metric 2, localpref 100, valid, external, best, group-best

Received Path ID 0, Local Path ID 1, version 76

Origin-AS validity: not-found

Tuttavia, il router ASBR intermedio non esegue BGP e non può inoltrare i pacchetti ricevuti con questa etichetta, in quanto non ha assegnato l'etichetta 24000. L'etichetta da utilizzare per portare i pacchetti a 10.100.1.5 è l'etichetta di LDP:

RP/0/0/CPU0:ASBR1#show route 10.100.1.5/32

Routing entry for 10.100.1.5/32

Known via "bgp 1", distance 20, metric 2, [ei]-bgp, labeled unicast (3107)

Tag 2, type external

Installed Apr  8 10:02:38.082 for 01:24:37

Routing Descriptor Blocks

10.100.1.4, from 10.100.1.4, BGP external

Route metric is 2

No advertising protos.

Questa operazione viene ripetuta all'hop successivo 10.100.1.4, il loopback di ASBR2.

Si consiglia di utilizzare l'etichetta ricevuta da ASBR3 da LDP, ma non lo è.

Lo stack di etichette aggiunto è {ImplNull 24000} anziché {24002 24000}.

RP/0/0/CPU0:ASBR1#show mpls ldp bindings 10.100.1.4/32

10.100.1.4/32, rev 146

Local binding: label: 24004

Remote bindings: (2 peers)

Peer                Label

-----------------   ---------

10.100.1.2:0        24003

10.100.1.7:0        24002

ASBR1 deve imporre l'etichetta LDP 24002 ricevuta dal router ASBR3. Per disabilitare l'inoltro MPLS BGP, aggiungere la parola chiave mpls al comando multi-hop eBGP.

ASBR1:

router bgp 1

…

neighbor 10.100.1.4

remote-as 2

ebgp-multihop 2 mpls

update-source Loopback0

address-family ipv4 labeled-unicast

route-policy PASS in

route-policy PASS out

!

ASBR1 dispone ora della riscrittura etichetta corretta:

RP/0/0/CPU0:ASBR1#show cef 10.100.1.5

10.100.1.5/32, version 155, internal 0x5000001 0x0 (ptr 0xa13be174) [1], 0x0 (0xa138965c), 0xa08 (0xa14a72d0)

Updated Apr  8 10:02:38.102

Prefix Len 32, traffic index 0, precedence n/a, priority 4

via 10.100.1.4/32, 5 dependencies, recursive, bgp-ext [flags 0x6020]

path-idx 0 NHID 0x0 [0xa150f874 0x0]

recursion-via-/32

next hop 10.100.1.4/32 via 24004/0/21

local label 24007

next hop 10.4.1.7/32 Gi0/0/0/4    labels imposed {24002 24000}

Dal riferimento del comando:

L'uso dell'opzione mpls nel comando ebgp-multihop impedisce a BGP di abilitare MPLS sull'interfaccia peer e impedisce inoltre l'allocazione di etichette di riscrittura Implicit-NULL per gli indirizzi dell'hop successivo appresi dal peer. Ciò è utile in alcuni scenari in cui le etichette di inoltro MPLS agli hop successivi sono già state apprese tramite BGP etichettato come unicast o LDP.

In altre parole, in IOS-XR, quando BGP offre di allocare un'etichetta all'LFIB, avrà la precedenza su LDP. Lo scenario dell'opzione Inter-AS C con più hop tra i router ASBR è uno scenario di questo tipo.

6. Opzione B tra appliance ASA - L'etichetta BGP è preferita all'etichetta LDP

Immagine 6.

Questa è l'opzione B di Inter-AS. Tuttavia, sono presenti più collegamenti paralleli tra le due ASBR. Tra gli ASBR è presente la RFC3107 (scambio di route IPv4 ed etichette MPLS), che consente di evitare l'utilizzo di IGP e LDP.

Per visualizzare la sessione multihop eBGP tra le interfacce di loopback di ASBR1 e ASBR2, è necessario disporre di eBGP LU tra le due ASBR. Poiché esistono due collegamenti tra gli ASBR, sono necessarie due sessioni eBGP LU. Il comando allocate-label è richiesto per la famiglia di indirizzi IPv4.

router bgp 65001

address-family ipv4 unicast

network 10.100.1.3/32

allocate-label all

!

neighbor 10.3.1.4

remote-as 65002

address-family ipv4 labeled-unicast

route-policy pass in

route-policy pass out

!

!

neighbor 10.3.2.4

remote-as 65002

address-family ipv4 labeled-unicast

route-policy pass in

route-policy pass out

!

!

Le route statiche dalla sezione 1 sono ancora necessarie:

router static

address-family ipv4 unicast

10.3.1.4/32 GigabitEthernet0/0/0/1

10.3.2.4/32 GigabitEthernet0/0/0/2

!

!

La sessione eBGP vpnv4 tra le appliance ASBR:

router bgp 65001

address-family ipv4 unicast

network 10.100.1.3/32

allocate-label all

!

address-family vpnv4 unicast

retain route-target all

!

neighbor 10.100.1.4

remote-as 65002

ebgp-multihop 255

update-source Loopback0

address-family vpnv4 unicast

route-policy pass in

route-policy pass out

!

!

Si noti che la parola chiave mpls non è necessaria in questo caso, come nella sezione 5. Inoltre, le sessioni LU iBGP tra PE e ASBR non sono necessarie se l'opzione next-hop-self è configurata per le sessioni iBGP vpnv4. L'etichetta pubblicizzata da ASBR2 per 10.100.1.4/32 è l'etichetta 3:

RP/0/0/CPU0:ASBR1#show bgp ipv4 labeled-unicast 10.100.1.4/32

Fri Jun  2 11:50:16.178 UTC

BGP routing table entry for 10.100.1.4/32

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                  8           8

Local Label: 24005

Last Modified: Jun  2 11:48:39.920 for 00:01:36

Paths: (4 available, best #1)

Advertised to update-groups (with more than one peer):

0.3

Advertised to peers (in unique update groups):

10.100.1.7

Path #1: Received by speaker 0

Advertised to update-groups (with more than one peer):

0.3

Advertised to peers (in unique update groups):

10.100.1.7

65002

10.3.1.4 from 10.3.1.4 (10.100.1.4)

Received Label 3

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

Received Path ID 0, Local Path ID 1, version 8

Origin-AS validity: not-found

Path #2: Received by speaker 0

Not advertised to any peer

65002

10.3.2.4 from 10.3.2.4 (10.100.1.4)

Received Label 3

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

Received Path ID 0, Local Path ID 0, version 0

Origin-AS validity: not-found

Path #3: Received by speaker 0

Not advertised to any peer

65003 65002

10.3.3.9 from 10.3.3.9 (10.100.1.9)

Received Label 24001

Origin IGP, localpref 100, valid, external, group-best

Received Path ID 0, Local Path ID 0, version 0

Origin-AS validity: not-found

Path #4: Received by speaker 0

Not advertised to any peer

65003 65002

10.3.4.9 from 10.3.4.9 (10.100.1.9)

Received Label 24001

Origin IGP, localpref 100, valid, external

Received Path ID 0, Local Path ID 0, version 0

Origin-AS validity: not-found

RP/0/0/CPU0:ASBR1#show cef 10.100.1.4

Fri Jun  2 11:51:06.994 UTC

10.100.1.4/32, version 254, internal 0x1000001 0x0 (ptr 0xa13be474) [1], 0x0 (0xa13896ec), 0xa20 (0xa14a70f0)

Updated Jun  2 11:48:39.634

local adjacency 10.3.1.4

Prefix Len 32, traffic index 0, precedence n/a, priority 4

via 10.3.1.4/32, GigabitEthernet0/0/0/1, 5 dependencies, weight 0, class 0 [flags 0x0]

path-idx 0 NHID 0x0 [0xa0e8b1fc 0xa0e8b34c]

next hop 10.3.1.4/32

local adjacency

local label 24005      labels imposed {ImplNull}

RP/0/0/CPU0:ASBR1#show mpls forwarding labels 24005

Fri Jun  2 11:51:20.204 UTC

Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes

Label  Label       or ID              Interface                    Switched

------ ----------- ------------------ ------------ --------------- ------------

24005  Pop         10.100.1.4/32      Gi0/0/0/1    10.3.1.4        610

Quando tra le ASBR è presente un altro percorso che utilizza i protocolli IGP + LDP o MPLS TE, la parola chiave mpls è necessaria per il comando eBGP multihop.

Immagine 7.

Una route policy BGP su ASBR1 verso P3 viene utilizzata per impostare il peso su un valore molto alto, in modo che i prefissi di P3 siano preferiti rispetto a quelli di ASBR2 direttamente.

RP/0/0/CPU0:ASBR1#show bgp ipv4 labeled-unicast 10.100.1.4/32

Fri Jun  2 11:57:23.789 UTC

BGP routing table entry for 10.100.1.4/32

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                  9           9

Local Label: 24005

Last Modified: Jun  2 11:51:58.920 for 00:05:24

Paths: (4 available, best #3)

Advertised to update-groups (with more than one peer):

0.3

Advertised to peers (in unique update groups):

10.100.1.7

Path #1: Received by speaker 0

Not advertised to any peer

65002

10.3.1.4 from 10.3.1.4 (10.100.1.4)

Received Label 3

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

Received Path ID 0, Local Path ID 0, version 0

Origin-AS validity: not-found

Path #2: Received by speaker 0

Not advertised to any peer

65002

10.3.2.4 from 10.3.2.4 (10.100.1.4)

Received Label 3

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

Received Path ID 0, Local Path ID 0, version 0

Origin-AS validity: not-found

Path #3: Received by speaker 0

Advertised to update-groups (with more than one peer):

0.3

Advertised to peers (in unique update groups):

10.100.1.7

65003 65002

10.3.3.9 from 10.3.3.9 (10.100.1.9)

Received Label 24001

Origin IGP, localpref 100, weight 65535, valid, external, best, group-best

Received Path ID 0, Local Path ID 1, version 9

Origin-AS validity: not-found

Path #4: Received by speaker 0

Not advertised to any peer

65003 65002

10.3.4.9 from 10.3.4.9 (10.100.1.9)

Received Label 24001

Origin IGP, localpref 100, valid, external

Received Path ID 0, Local Path ID 0, version 0

Origin-AS validity: not-found

ASBR1 deve ora utilizzare l'etichetta 24001 come etichetta in uscita per 10.100.1.4/32, ma non:

RP/0/0/CPU0:ASBR1#show cef 10.100.1.4

Fri Jun  2 11:59:46.519 UTC

10.100.1.4/32, version 255, internal 0x1000001 0x0 (ptr 0xa13be474) [1], 0x0 (0xa13896ec), 0xa20 (0xa14a7140)

Updated Jun  2 11:51:58.741

local adjacency 10.3.3.9

Prefix Len 32, traffic index 0, precedence n/a, priority 4

via 10.3.3.9/32, GigabitEthernet0/0/0/3, 7 dependencies, weight 0, class 0 [flags 0x0]

path-idx 0 NHID 0x0 [0xa0e8b544 0xa0e8b5ec]

next hop 10.3.3.9/32

local adjacency

local label 24005      labels imposed {ImplNull}

La soluzione è la stessa della sezione 5: usare la parola chiave mpls per il comando eBGP multihop.

RP/0/0/CPU0:ASBR1# conf t

Fri Jun  2 13:56:45.618 UTC

RP/0/0/CPU0:ASBR1(config)#router bgp 65001

RP/0/0/CPU0:ASBR1(config-bgp)# neighbor 10.100.1.4

RP/0/0/CPU0:ASBR1(config-bgp-nbr)#ebgp-multihop 255 mpls

RP/0/0/CPU0:ASBR1(config-bgp-nbr)#commit

ASBR1 utilizza ora l'etichetta 24001 come etichetta in uscita per 10.100.1.4/32.

RP/0/0/CPU0:ASBR1#show cef 10.100.1.4

Fri Jun  2 13:58:13.402 UTC

10.100.1.4/32, version 200, internal 0x5000001 0x0 (ptr 0xa13be474) [1], 0x0 (0xa13895cc), 0xa08 (0xa14a71b8)

Updated Jun  2 13:56:59.378

Prefix Len 32, traffic index 0, precedence n/a, priority 15

via 10.3.3.9/32, 3 dependencies, recursive, bgp-ext [flags 0x6020]

path-idx 0 NHID 0x0 [0xa15102f4 0x0]

recursion-via-/32

next hop 10.3.3.9/32 via 24014/0/21

local label 24005

next hop 10.3.3.9/32 Gi0/0/0/3    labels imposed {ImplNull 24001}

ASBR1 spinge questa etichetta extra. Un traceroute nel VRF (Virtual Routing and Forwarding) da PE1 a PE2 mostra le etichette aggiuntive sottoposte a push.

RP/0/0/CPU0:PE1#trace vrf one 10.99.1.2

Fri Jun  2 13:49:38.959 UTC

Type escape sequence to abort.

Tracing the route to 10.99.1.2

1  10.1.1.5 [MPLS: Labels 24002/24012 Exp 0] 29 msec  39 msec  39 msec

2  10.1.2.3 [MPLS: Label 24012 Exp 0] 29 msec  29 msec  39 msec

3  10.3.1.4 [MPLS: Label 24007 Exp 0] 39 msec  39 msec  39 msec

4  10.2.1.6 [MPLS: Labels 24001/24005 Exp 0] 39 msec  39 msec  29 msec

5  10.2.2.2 39 msec  *  239 msec

IGP e LDP sono stati utilizzati tra ASBR1 e P3 e ASBR2 e P3. Lo stesso problema e la stessa soluzione si verificano quando tra questi router viene utilizzato MPLS Traffic Engineering (TE).

Non esiste un LDP da ASBR1 a P3, ma esiste MPLS TE.

Senza la parola chiave mpls sul comando eBGP multihop, si torna allo stesso problema:

I pacchetti inoltrati alla versione 10.100.1.4 non ricevono l'etichetta BGP LU 24000 con push.

RP/0/0/CPU0:ASBR1#show cef 10.100.1.4

Tue Jun  6 10:36:56.528 UTC

10.100.1.4/32, version 50, internal 0x1000001 0x0 (ptr 0xa12cc1fc) [1], 0x0 (0xa12b18c0), 0xa20 (0xa14a7258)

Updated Jun  6 10:36:32.930

Prefix Len 32, traffic index 0, precedence n/a, priority 4

via 10.3.3.9/32, tunnel-te1, 7 dependencies, weight 0, class 0 [flags 0x0]

path-idx 0 NHID 0x0 [0xa15d58f8 0xa15d5840]

next hop 10.3.3.9/32

local adjacency

local label 24012      labels imposed {ImplNull}

mentre con la parola chiave mpls, l'etichetta 24000 è presente:

RP/0/0/CPU0:ASBR1#show cef 10.100.1.4

Tue Jun  6 10:36:03.241 UTC

10.100.1.4/32, version 34, internal 0x5000001 0x0 (ptr 0xa12cc1fc) [1], 0x0 (0xa12b15a8), 0xa08 (0xa14a70f0)

Updated Jun  6 09:39:24.56

Prefix Len 32, traffic index 0, precedence n/a, priority 15

Extensions: context-label:24012

via 10.3.3.9/32, 3 dependencies, recursive, bgp-ext [flags 0x6020]

path-idx 0 NHID 0x0 [0xa150fecc 0x0]

recursion-via-/32

next hop 10.3.3.9/32 via 24011/0/21

local label 24012

next hop 10.3.3.9/32 tt1          labels imposed {ImplNull 24000}

Con la parola chiave mpls la riscrittura avrà il seguente aspetto:

RP/0/0/CPU0:ASBR1#show mpls forwarding labels 24012

Tue Jun  6 10:43:50.559 UTC

Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes

Label  Label       or ID              Interface                    Switched

------ ----------- ------------------ ------------ --------------- ------------

24012  24000       10.100.1.4/32      tt1          10.3.3.9        0

Senza la parola chiave mpls, la riscrittura avrà il seguente aspetto:

RP/0/0/CPU0:ASBR1#show mpls forwarding labels 24012

Tue Jun  6 10:45:08.734 UTC

Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes

Label  Label       or ID              Interface                    Switched

------ ----------- ------------------ ------------ --------------- ------------

24012  Pop         10.100.1.4/32      tt1          10.3.3.9        0

Questa etichetta 14012 non viene utilizzata per il traffico da VRF a VRF o da PE a PE, ma se rilevata, potrebbe indicare che la voce della base dell'istanza di inoltro etichette (LFIB) è errata o non è corretta.

RP/0/0/CPU0:PE1# trace vrf one 10.99.1.2

Type escape sequence to abort.

Tracing the route to 10.99.1.2

1  10.1.1.5 [MPLS: Labels 24001/24015 Exp 0] 129 msec  229 msec  129 msec

2  10.1.2.3 [MPLS: Label 24015 Exp 0] 219 msec  439 msec  349 msec

3  10.3.3.9 [MPLS: Labels 24000/24011 Exp 0] 169 msec  249 msec  139 msec

4  10.3.5.4 [MPLS: Label 24011 Exp 0] 89 msec  129 msec  109 msec

5  10.2.1.6 [MPLS: Labels 24004/24008 Exp 0] 139 msec  99 msec  139 msec

6  10.2.2.2 129 msec  *  219 msec

La commutazione della parola chiave mpls sul comando eBGP multihop potrebbe causare una collisione del messaggio syslog per l'etichetta BGP:

bgp[1051]: %ROUTING-BGP-4-LABEL_COLLISION : Label 24012 collision: prev: [T: 3 RD:0:0:0 PFX/NHID:10.100.1.4/32] curr: [T: 13 RD:0:0:0 PFX/NHID:10.100.1.4/32]

Questo messaggio è per l'etichetta locale 24012.

Il controllo viene eseguito per garantire che un'etichetta attiva di proprietà di BGP non venga assegnata di nuovo da BGP per nessun altro motivo. Questo controllo è valido solo per le etichette per prefisso.

Questo messaggio è un sintomo e non la causa di alcun problema in questo articolo.

7. Sessione BGP multihop su VPN (o 6PE o EVPN) Underlay

In caso di sessione multi-hop di eBGP, il percorso per l'indirizzo dell'hop successivo non può essere individuato tramite una route vpnv4/6 o 6PE (IPv6 su MPLS) o Ethernet Virtual Private Network (EVPN), a meno che il router non sia dotato della versione Cisco IOS®-XR 6.3.2 o successive. Fare riferimento a questa immagine.

Immagine 8.

Possibili scenari di errore:

1. Sessione multi-hop eBGP da PE1 (all'interno di un VRF) a PE2 (all'interno di un VRF)

2. Sessione multi-hop eBGP da PE1 (all'interno di un VRF) a CE2

Ciò vale:

La sessione multi-hop eBGP è configurata nella sezione VRF del router BGP sul router PE.

La sessione multi-hop eBGP da PE1 (all'interno del VRF) a PE2 (all'interno del VRF) o la sessione multi-hop eBGP da PE1 (all'interno del VRF) a CE2, sono supportate solo a partire da Cisco IOS®-XR 6.3.2.

L'indirizzo del peer eBGP è raggiungibile sulla base dell'indirizzo che consiste di vnpv4. vpnv6, 6PE o EVPN.

Nelle versioni Cisco IOS® precedenti alla 6.3.2, la sessione eBGP sarà inattiva.

Ad esempio, la sessione multi-hop eBGP da PE1 a PE2 in VRF 1 è configurata.

Configurazione appropriata per la sessione multi-hop eBGP da PE1 a PE2 in PE1:

interface Loopback100

vrf one

ipv4 address 10.2.100.1 255.255.255.255

router bgp 1

address-family vpnv4 unicast

!

neighbor 10.100.1.2

remote-as 1

update-source Loopback0

address-family vpnv4 unicast

!

!

vrf one

rd 1:1

address-family ipv4 unicast

redistribute connected

!

neighbor 10.2.100.2

remote-as 65002

ebgp-multihop 255

local-as 65001

update-source Loopback100

address-family ipv4 unicast

route-policy pass in

route-policy pass out

!

!

!

!

La sessione eBGP rimane inattiva:

RP/0/0/CPU0:PE1#show bgp vrf one neighbors

BGP neighbor is 10.2.100.2, vrf one

Remote AS 65002, local AS 65001, external link

Remote router ID 0.0.0.0

BGP state = Idle (No route to multi-hop neighbor)

La route per l'indirizzo peer eBGP è presente nella tabella di routing VRF one:

RP/0/0/CPU0:PE1# show route vrf one

Codes: C - connected, S - static, R - RIP, B - BGP, (>) - Diversion path

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, su - IS-IS summary null, * - candidate default

U - per-user static route, o - ODR, L - local, G - DAGR

A - access/subscriber, a - Application route, (!) - FRR Backup path

Gateway of last resort is not set

L 10.2.100.1/32 is directly connected, 00:23:25, Loopback100

B 10.2.100.2/32 [200/0] via 10.100.1.2 (nexthop in vrf default), 00:19:28

RP/0/0/CPU0:PE1# show route vrf one 10.2.100.2/32

Routing entry for 10.2.100.2/32

Known via "bgp 1", distance 200, metric 0, type internal

Installed May 29 09:07:53.368 for 00:19:36

Routing Descriptor Blocks

10.100.1.2, from 10.100.1.2

Nexthop in Vrf: "default", Table: "default", IPv4 Unicast, Table Id: 0xe0000000

Route metric is 0

No advertising protos.

La causa sottostante del problema è che la route per l'indirizzo peer è una route importata:

RP/0/0/CPU0:PE1# show bgp vpnv4 unicast vrf one 10.2.100.2/32

BGP routing table entry for 10.2.100.2/32, Route Distinguisher: 1:1

Versions:

Process bRIB/RIB SendTblVer

Speaker 7 7

Last Modified: May 29 09:07:53.524 for 00:21:20

Paths: (1 available, best #1)

Not advertised to any peer

Path #1: Received by speaker 0

Not advertised to any peer

Local

10.100.1.2 (metric 2) from 10.100.1.2 (10.100.1.2)

Received Label 16001

Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported

Received Path ID 0, Local Path ID 1, version 7

Extended community: RT:1:1

Source VRF: one, Source Route Distinguisher: 1:1

Questa funzione è supportata dopo Cisco IOS®-XR 6.3.2.

8. Ridistribuzione di BGP in LDP

Questo è il significato di MPLS unificato o senza interruzioni e la sua configurazione con IOS-XR: MPLS unificato con IOS-XR

Con MPLS unificato standard, esiste una LU BGP tra tutti i router PE e ABR, come mostrato nell'immagine.

Immagine 9.

Immagine 10.

Nell'esempio, esiste un'area/livello IGP senza BGP LU. A sinistra, l'area di aggregazione è in realtà il processo OSPF (Open Shortest Path First) 1, che non ha una ridistribuzione con il processo OSPF 2 nel nucleo. Nella parte della rete con OSPF 1, non è presente alcuna LU BGP tra i router PE e i router ABR (Area Border Router).

Immagine 11.

I prefissi BGP LU vengono ridistribuiti nell'IGP OSPF 1 su ABR1 come mostrato nell'immagine.

Immagine 12.

È necessario disporre di BGP per allocare l'etichetta per i prefissi LU iBGP ricevuti. Tuttavia, questa etichetta non viene automaticamente annunciata da LDP nell'associazione etichetta per il prefisso ridistribuito. Per impostazione predefinita, IOS(-XE) esegue questa operazione.

Si noti che ABR sta ridistribuendo le route BGP interne nell'IGP nell'area sinistra. Ciò significa che il comando bgp redistribute-internal è richiesto con il router bgp.

router bgp 1

bgp redistribute-internal

router ospf 1

router-id 10.100.1.3

redistribute bgp 1 metric 10 route-policy select-to-allocate

area 0

interface Loopback0

!

interface GigabitEthernet0/0/0/0

network point-to-point

!

!

!

route-policy select-to-allocate

if destination in (10.100.1.7/32) then

pass

else

drop

endif

end-policy

Quando è abilitata l'allocazione delle etichette locali, ABR assegna un'etichetta locale alle route LU iBGP ricevute.

router bgp 1

bgp redistribute-internal

ibgp policy out enforce-modifications

address-family ipv4 unicast

redistribute ospf 1 metric 10 route-policy ospf-1-loopbacks-PE

allocate-label route-policy select-to-allocate

La selezione per l'allocazione dei criteri di route può essere utilizzata per specificare a quali prefissi LU BGP ricevuti viene assegnata un'etichetta locale.

route-policy select-to-allocate

if destination in (10.100.1.7/32) then

pass

else

drop

endif

end-policy

!

Il prefisso di loopback di PE2 è visibile su ABR1 con un'etichetta locale, ma LDP non vede questa etichetta locale:

RP/0/0/CPU0:ABR1#show bgp ipv4 labeled-unicast 10.100.1.7/32

BGP routing table entry for 10.100.1.7/32

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                  6           6

Local Label: 24006

Last Modified: Sep  5 06:55:47.368 for 06:40:23

Paths: (1 available, best #1)

Advertised IPv4 Labeled-unicast paths to update-groups (with more than one peer):

0.2

Path #1: Received by speaker 0

Advertised IPv4 Labeled-unicast paths to update-groups (with more than one peer):

0.2

Local, (Received from a RR-client)

10.100.1.5 (metric 20) from 10.100.1.5 (10.100.1.7)

Received Label 24003

Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, labeled-unicast

Received Path ID 0, Local Path ID 1, version 6

Originator: 10.100.1.7, Cluster list: 10.100.1.5

RP/0/0/CPU0:ABR1#show mpls ldp bindings 10.100.1.7/32

10.100.1.7/32, rev 0 (no route)

No local binding

Remote bindings: (1 peers)

Peer                Label

-----------------   ---------

10.100.1.2:0        18

Ciò significa che l'LSP da PE1 a PE2 viene interrotto:

RP/0/0/CPU0:PE1#traceroute 10.100.1.7 source 10.100.1.1

Type escape sequence to abort.

Tracing the route to 10.100.1.7

1  10.1.1.2 [MPLS: Label 18 Exp 0] 9 msec  0 msec  0 msec

2  10.1.2.3 0 msec  0 msec  0 msec <<< no MPLS labels

3  10.1.3.4 [MPLS: Labels 16/24003 Exp 0] 29 msec  19 msec  29 msec

4  10.1.4.5 [MPLS: Label 24003 Exp 0] 9 msec  9 msec  9 msec

5   *  *  *

6  10.1.6.7 9 msec  *  19 msec

L'LSP viene interrotto in corrispondenza di P2 perché non ha ricevuto un'etichetta remota tramite LDP da ABR1. Ad ABR1 non è stata assegnata localmente l'etichetta per il prefisso 10.100.1.7/32 in LDP.

È necessaria una configurazione sull'ABR per ridistribuire BGP in LDP sul router su cui la route BGP viene ridistribuita nell'IGP.

ABR1 non annuncia un binding di etichetta LDP per il prefisso 10.100.1.7/32 al router P2.

Affinché ABR1 possa annunciare il binding dell'etichetta LDP per i prefissi iBGP ridistribuiti, è necessario che ABR1 abbia la seguente configurazione (il numero AS deve essere configurato).

mpls ldp

mldp

address-family ipv4

!

!

router-id 10.100.1.3

address-family ipv4

redistribute

bgp

as 1

!

!

!

È possibile impostare il filtro LDP per gli annunci. È ad esempio possibile configurare un filtro simile al seguente:

mpls ldp

mldp

address-family ipv4

!

!

router-id 10.100.1.3

address-family ipv4

redistribute

bgp

as 1

advertise-to 1

!

ipv4 access-list 1

10 permit ipv4 host 10.100.1.2 any

L'ID del router LDP viene specificato nell'elenco degli accessi.

In questo esempio, ABR annuncia solo i binding LDP per le route iBGP ridistribuite al router adiacente LDP P2 (e non a P1), poiché 10.100.1.2 è l'ID router LDP di P2.

L'LSP da PE1 a PE2 è ora ininterrotto:

RP/0/0/CPU0:PE1#traceroute 10.100.1.7 source 10.100.1.1

Type escape sequence to abort.

Tracing the route to 10.100.1.7

1  10.1.1.2 [MPLS: Label 20 Exp 0] 39 msec  49 msec  29 msec

2  10.1.2.3 [MPLS: Label 24006 Exp 0] 29 msec  49 msec  39 msec

3  10.1.3.4 [MPLS: Labels 16/24003 Exp 0] 29 msec  19 msec  29 msec

4  10.1.4.5 [MPLS: Label 24003 Exp 0] 29 msec  19 msec  29 msec

5   *  *  *

6  10.1.6.7 19 msec  *  19 msec

Immagine 13.

L'etichetta assegnata BGP (24006) annunciata da LDP nell'area di aggregazione sinistra è ora utilizzata per il traffico da PE1 a PE2.

Si noti che nell'area di aggregazione sinistra viene utilizzata una sola etichetta MPLS. Se si tratta di un MPLS unificato standard, vengono utilizzate due etichette.

A questo punto, non è possibile filtrare le route LU iBGP ridistribuite in LDP, che riceveranno un'etichetta locale e quali no. Non appena la ridistribuzione delle route iBGP LU in LDP è abilitata, tutti ottengono un'etichetta locale.

PE2 inoltre annuncia il prefisso 10.100.1.99/32 in BGP LU. Questo prefisso non viene ridistribuito da ABR1 in OSPF 1. Tuttavia, non appena la ridistribuzione delle route LU iBGP in LDP è stata attivata, il prefisso 10.100.1.99/32 ha anche un'etichetta locale.

RP/0/0/CPU0:ABR1#show mpls ldp bindings 10.100.1.99/32

10.100.1.99/32, rev 24

Local binding: label: 24007

No remote bindings

9. Comando MPLS Activate Interface

Esempio 1. IGP ma non LDP

Il comando mpls activate è necessario se un IGP si occupa del routing interno, ma non è disponibile alcun LDP per annunciare i binding delle etichette. Se ogni hop esegue BGP, è possibile utilizzare BGP LU per annunciare prefissi ed etichette. Quando è iBGP su un collegamento, il collegamento deve essere abilitato sul router BGP con il comando mpls activate. Fare riferimento a questa immagine.

Immagine 14.

R1 e R2 eseguono una LU IGP e iBGP tra loro. R1 e R2 sono collegati direttamente. R2 ha una sessione LU eBGP con R3.

R3 annuncia il prefisso da 10.100.100.3/2 a R2 su una sessione eBGP LU. R2 annuncia questo prefisso a R1 su una sessione LU iBGP.

L'obiettivo è avere un provider di servizi di traduzione ininterrotto da R1 a R3. È lì?

RP/0/0/CPU0:R1#trace 10.100.100.3 so 10.100.100.1

Type escape sequence to abort.

Tracing the route to 10.100.100.3

1 100.1.1 !N *  !N

Non esiste un'etichetta per questo prefisso al primo hop.

RP/0/0/CPU0:R1#traceroute mpls ipv4 10.100.100.3/32 ttl 5

Tracing MPLS Label Switched Path to 10.100.100.3/32, timeout is 2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,

'L' - labeled output interface, 'B' - unlabeled output interface,

'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,

'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,

'P' - no rx intf label prot, 'p' - premature termination of LSP,

'R' - transit router, 'I' - unknown upstream index,

'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

0 0.0.0.0 MRU 0 [No Label]

Q 1 *

Quindi, non c'è nessuna etichetta. Non è una sorpresa, perché MPLS non è abilitato sull'interfaccia di R2:

RP/0/0/CPU0:R1#show mpls interfaces

RP/0/0/CPU0:R1#

Il prefisso LU annunciato da R3 è tuttavia presente in R1:

RP/0/0/CPU0:R1#show bgp ipv4 labeled-unicast 10.100.100.3/32

BGP routing table entry for 10.100.100.3/32

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                  7           7

Local Label: 24001

Last Modified: Sep 13 14:27:17.510 for 00:11:39

Paths: (1 available, best #1)

Not advertised to any peer

Path #1: Received by speaker 0

Not advertised to any peer

65001

10.100.1.2 (metric 2) from 10.100.1.2 (10.100.1.2)

Received Label 24002

Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, labeled-unicast

Received Path ID 0, Local Path ID 1, version 7

È possibile configurare il comando mpls active su R1 per l'interfaccia su R2:

router bgp 65000

mpls activate

interface GigabitEthernet0/0/0/0

!

address-family ipv4 unicast

network 10.100.100.1/32

allocate-label all

!

neighbor 10.100.1.2

remote-as 65000

update-source Loopback0

address-family ipv4 labeled-unicast

!

!

!

MPLS è ora abilitato sull'interfaccia in uscita.

RP/0/0/CPU0:R1#show mpls interfaces

Interface                  LDP      Tunnel   Static   Enabled

-------------------------- -------- -------- -------- --------

GigabitEthernet0/0/0/0     No       No       No       Yes

Il comando traceroute ora mostra che l'LSP è ininterrotto.

RP/0/0/CPU0:R1#trace 10.100.100.3 so 10.100.100.1

Type escape sequence to abort.

Tracing the route to 10.100.100.3

1  10.1.2.2 [MPLS: Label 24002 Exp 0] 39 msec  9 msec  9 msec

2  10.2.3.3 19 msec *  9 msec

RP/0/0/CPU0:R1#traceroute mpls ipv4 10.100.100.3/32 ttl 5 source 10.100.100.1

Tracing MPLS Label Switched Path to 10.100.100.3/32, timeout is 2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,

'L' - labeled output interface, 'B' - unlabeled output interface,

'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,

'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx labl,

'P' - no rx intf label prot, 'p' - premature termination of LSP,

'R' - transit router, 'I' - unknown upstream index,

'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

0 10.1.2.1 MRU 1500 [Labels: implicit-null/24002 Exp: 0/0]

L 1 10.1.2.2 MRU 1500 [Labels: implicit-null/implicit-null Exp: 0/0] 0 ms

! 2 10.2.3.3 10 ms

Esempio 2. Confederazione

Nell'esempio viene mostrato che il comando mpls activate è richiesto sui collegamenti di confederazione eBGP (inter-AS) quando si usa BGP LU (RFC 3107) e non si usa LDP.

La rete in questa immagine è una confederazione 6500 con sistemi subautonomi 65501, 65502, 65503 e 65504.

Immagine 15.

L'idea è quella di avere un LSP MPLS da R1 a R8 (10.0.0.8/32 viene pubblicizzato da R8 in BGP LU) utilizzando BGP LU in entrambi i sistemi autonomi.

C'è una LU eBGP regolare tra R7 e R8. C'è una iBGP riconosciuta tra R2 e R4 e tra R5 e R6. C'è una eBGP confermata tra R1 e R2, R4 e R5 e tra R6 e R7. C'è un hop successivo-self in ogni sessione eBGP.

La route statica all'hop successivo del peer eBGP (tipica per le sessioni BGP inter-AS) è necessaria perché esiste eBGP tra i sistemi subautonomi all'interno della confederazione.

Sarà sufficiente per effettuare la connettività tra R1 e R8? Ciò significa che l'obiettivo è avere un LSP ininterrotto da R1 a R8.

Controlla questo.

RP/0/0/CPU0:R1#traceroute 10.0.0.8

Type escape sequence to abort.

Tracing the route to 10.0.0.8

1   *  *  *

2   *  *  *

3   *  *  *

4   *  *  *

5   *  *  *

Il comando traceroute non restituisce hop/etichette e continuerà se non viene specificato alcun limite TTL. I router probabilmente rispondono al traceroute, ma i pacchetti potrebbero non essere in grado di tornare alla versione R1. Eseguire il traceroute mpls, che è la scelta più sicura.

Nota: Il comando traceroute MPLS funziona solo se l'OAM MPLS è abilitato su ogni router del percorso.

RP/0/0/CPU0:R1#trace mpls ipv4 10.0.0.8/32

Tracing MPLS Label Switched Path to 10.0.0.8/32, timeout is 2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,

'L' - labeled output interface, 'B' - unlabeled output interface,

'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,

'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,

'P' - no rx intf label prot, 'p' - premature termination of LSP,

'R' - transit router, 'I' - unknown upstream index,

'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

0 10.1.2.1 MRU 1500 [Labels: implicit-null/24015 Exp: 0/0]

L 1 10.1.2.2 MRU 1500 [Labels: 24003/24014 Exp: 0/0] 10 ms

L 2 10.2.3.3 MRU 1500 [Labels: implicit-null/24014 Exp: 0/0] 10 ms

N 3 10.3.4.4 MRU 0 [No Label] 10 ms

Il problema si verifica in R4. L'interfaccia in uscita non è presente in LFIB:

RP/0/0/CPU0:R4#show mpls forwarding prefix 10.0.0.8/32

Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes

Label  Label       or ID              Interface                    Switched

------ ----------- ------------------ ------------ --------------- ------------

24014  24014       10.0.0.8/32                     10.4.5.5        5140

La voce in CEF non è risolta:

RP/0/0/CPU0:R4#show cef 10.0.0.8/32

10.0.0.8/32, version 109, drop adjacency, internal 0x5000001 0x0 (ptr 0xa14160e4) [1], 0x0 (0xa13f83c8), 0xa08 (0xa16cd370)

Updated Sep 13 12:43:30.252

Prefix Len 32, traffic index 0, precedence n/a, priority 4

via 10.4.5.5/32, 0 dependencies, recursive [flags 0x6000]

path-idx 0 NHID 0x0 [0xa0f182d8 0x0]

recursion-via-/32

unresolved

local label 24014

labels imposed {24014}

MPLS non è abilitato sull'interfaccia GE0/0/0/1:

RP/0/0/CPU0:R4#show mpls interfaces

Interface                  LDP      Tunnel   Static   Enabled

-------------------------- -------- -------- -------- --------

GigabitEthernet0/0/0/0     Yes      No       No       Yes

Il problema viene risolto con il comando di attivazione di MPLS per BGP sul collegamento tra R4 e R5. R4 e R5 hanno una sessione di confederazione eBGP su questo collegamento. In realtà, si tratta di una sessione iBGP all'interno della confederazione 6500. Di conseguenza, il comando per attivare MPLS è necessario per assicurarsi che il prefisso su R4 venga risolto nell'hop successivo R5. In altre reti regolari, questo problema sarebbe risolto da LDP, ma qui non c'è LDP tra R4 e R5 perché si tratta di una sessione eBGP all'interno della confederazione.

Aggiungere il comando mpls activate per l'interfaccia ge 0/0/0/1 su R4:

router bgp 65502

bgp confederation peers

65501

65503

65504

!

bgp confederation identifier 65000

mpls activate

interface GigabitEthernet0/0/0/1

!

…

RP/0/0/CPU0:R4#show mpls interfaces

Interface                  LDP      Tunnel   Static   Enabled

-------------------------- -------- -------- -------- --------

GigabitEthernet0/0/0/0     Yes      No       No       Yes

GigabitEthernet0/0/0/1     No       No       No       Yes

Il traceroute ora rivela un LSP ininterrotto da R1 a R8.

RP/0/0/CPU0:R1#trace mpls ipv4 10.0.0.8/32

Tracing MPLS Label Switched Path to 10.0.0.8/32, timeout is 2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,

'L' - labeled output interface, 'B' - unlabeled output interface,

'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,

'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label

'P' - no rx intf label prot, 'p' - premature termination of LSP,

'R' - transit router, 'I' - unknown upstream index,

'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

0 10.1.2.1 MRU 1500 [Labels: implicit-null/24015 Exp: 0/0]

L 1 10.1.2.2 MRU 1500 [Labels: 24003/24014 Exp: 0/0] 10 ms

L 2 10.2.3.3 MRU 1500 [Labels: implicit-null/24014 Exp: 0/0] 10 ms

L 3 10.3.4.4 MRU 1500 [Labels: implicit-null/24014 Exp: 0/0] 10 ms

L 4 10.4.5.5 MRU 1500 [Labels: implicit-null/24014 Exp: 0/0] 20 ms

L 5 10.5.6.6 MRU 1500 [Labels: implicit-null/24014 Exp: 0/0] 30 ms

L 6 10.6.7.7 MRU 1500 [Labels: implicit-null/implicit-null Exp: 0/0] 30 ms

! 7 10.7.8.8 30 ms

RP/0/0/CPU0:R1#traceroute 10.0.0.8

Type escape sequence to abort.

Tracing the route to 10.0.0.8

1  10.1.2.2 [MPLS: Label 24015 Exp 0] 69 msec  29 msec  29 msec

2  10.2.3.3 [MPLS: Labels 24003/24014 Exp 0] 49 msec  29 msec  29 msec

3  10.3.4.4 [MPLS: Label 24014 Exp 0] 19 msec  19 msec  19 msec

4  10.4.5.5 [MPLS: Label 24014 Exp 0] 49 msec  19 msec  29 msec

5  10.5.6.6 [MPLS: Label 24014 Exp 0] 19 msec  19 msec  29 msec

6  10.6.7.7 [MPLS: Label 24014 Exp 0] 29 msec  29 msec  29 msec

7  10.7.8.8 29 msec  *  29 msec

Esiste ora un'interfaccia in uscita in LFIB per questa voce:

RP/0/0/CPU0:R4#show mpls forwarding prefix 10.0.0.8/32

Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes

Label  Label       or ID              Interface                    Switched

------ ----------- ------------------ ------------ --------------- ------------

24014  24014       10.0.0.8/32        Gi0/0/0/1    10.4.5.5        2890

L'etichetta in uscita è presente su R4 per il prefisso e CEF mostra il prefisso come risolto:

RP/0/0/CPU0:R4#show cef 10.0.0.8/32

Updated Sep 13 12:43:30.252

Prefix Len 32, traffic index 0, precedence n/a, priority 4

via 10.4.5.5/32, 3 dependencies, recursive [flags 0x6000]

path-idx 0 NHID 0x0 [0xa17420e4 0x0]

recursion-via-/32

next hop 10.4.5.5/32 via 24016/0/21

local label 24014

next hop 10.4.5.5/32 Gi0/0/0/1    labels imposed {ImplNull 24014}