Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Convenciones

Proceso de registro

Configuraciones de ejecución relevantes

Depuraciones relevantes

Información Relacionada

Introducción

Puede lograr redundancia para el Punto de Encuentro (RP) si aplica protocolos como auto-RP y Bootstrap. Sin embargo, en caso de fracaso, su convergencia no es tan rápida. Hay un concepto de RP de difusión múltiple en el que se configura la misma dirección IP (rp-address) en dos o más routers que se desea utilizar como RP. A continuación, anuncie esta IP en IGP. Otros routers seleccionarán cualquiera de estos routers según la mejor trayectoria a la dirección rp. En caso de fallo, la convergencia es la misma que el protocolo de gateway interior (IGP).

Con este concepto surge un problema. La información debe sincronizarse entre los diferentes RPs porque pocos remitentes y receptores pueden unirse al router 1 que funciona como RP, y pocos pueden unirse al router 2 que funciona como RP. Estos routers no tendrían información completa de todos los orígenes y la multidifusión se rompería. La solución a este problema es tener un mecanismo para sincronizar la información con respecto a los orígenes entre todos los routers que actúan como RP. Hay dos protocolos que pueden servir para este propósito:

- Protocolo de detección de origen de multidifusión (MSDP)

- PIM

MSDP ha existido por un tiempo. Los mensajes activos de origen se envían a otros routers cada vez que un origen se registra en un RP. Hay una mejora de PIM que se detalla en este documento. Actualmente, esta mejora solo está disponible para Nexus.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

- RP de difusión inmediata

- PIM (Nexus)

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Proceso de registro

Esta es una topología de ejemplo:

Remitente(172.16.1.1)—(9/3)Nexus-1(9/2)—(9/2)Nexus-2

Configuraciones de ejecución relevantes

Configuración relevante de Nexus 1:

ip pim rp-address 10.1.1.1 group-list 224.0.0.0/4

ip pim anycast-rp 10.1.1.1 192.168.1.1

ip pim anycast-rp 10.1.1.1 192.168.2.2

interface loopback1

ip address 192.168.1.1/32

ip router ospf 1 area 0.0.0.0

ip pim sparse-mode

interface loopback7

ip address 10.1.1.1/32

ip router ospf 1 area 0.0.0.0

ip pim sparse-mode

interface Ethernet9/2

ip address 10.7.7.1/24

ip router ospf 1 area 0.0.0.0

ip pim sparse-mode

interface Ethernet9/3

ip address 172.16.1.2/24

ip router ospf 1 area 0.0.0.0

ip pim sparse-mode

Configuración relevante de Nexus 2:

ip pim rp-address 10.1.1.1 group-list 224.0.0.0/4

ip pim ssm range 232.0.0.0/8

ip pim anycast-rp 10.1.1.1 192.168.1.1

ip pim anycast-rp 10.1.1.1 192.168.2.2

interface loopback1

ip address 192.168.2.2/32

ip router ospf 1 area 0.0.0.0

ip pim sparse-mode

interface loopback7

ip address 10.1.1.1/32

ip router ospf 1 area 0.0.0.0

ip pim sparse-mode

interface Ethernet9/2

ip address 10.7.7.2/24

ip router ospf 1 area 0.0.0.0

ip pim sparse-mode

Hay dos cajas Nexus: Nexus-1 y Nexus-2. Ambos se utilizarán como RP. La dirección RP debe ser 10.1.1.1. El loopback 7 está en ambas cajas Nexus que tienen esta IP configurada. A continuación, este bucle invertido se anuncia en OSPF (Open Shortest Path First), de modo que los distintos routers de la red alcanzan Nexus-1 o Nexus-2 para el RP. Esto depende de la mejor métrica de trayectoria.

En ambos Nexus, 10.1.1.1 se define como el RP usando este comando:

ip pim rp-address 10.1.1.1 group-list 224.0.0.0/4

Ahora necesita definir algo llamado conjunto RP. Este es el conjunto de todos los routers que actuarían como RP. Debe tener un loopback en cada router RP prospectivo, que es diferente del loopback que se utiliza como dirección RP. En este ejemplo, el loopback 1 se encuentra en ambos Nexus que tienen la dirección IP 192.168.1.1/32 y 192.168.2.2/32, respectivamente. Este loopback 1 se utiliza para definir el conjunto RP. El comando para hacer lo mismo es:

ip pim anycast-rp <rp-address> <ip-address-of-prospective-RP>

Los comandos para ambos Nexus para la configuración son:

- ip pim anycast-rp 10.1.1.1 192.168.1.1

- ip pim anycast-rp 10.1.1.1 192.168.2.2

Una cosa a tener en cuenta aquí es que necesita definir su propia IP, así como en el conjunto RP. Por lo tanto, ambos comandos deben colocarse en ambos cuadros de Nexus.

Una vez definido el conjunto RP, éste es el resultado que ve para el mapeo RP:

Nexus-1# show ip pim rp

PIM RP Status Information for VRF "default"

BSR disabled

Auto-RP disabled

BSR RP Candidate policy: None

BSR RP policy: None

Auto-RP Announce policy: None

Auto-RP Discovery policy: None

Anycast-RP 10.1.1.1 members:

192.168.1.1*  192.168.2.2

RP: 10.1.1.1*, (0), uptime: 00:00:58, expires: never,

priority: 0, RP-source: (local), group ranges:

224.0.0.0/4

Nexus-2# show ip pim rp

PIM RP Status Information for VRF "default"

BSR disabled

Auto-RP disabled

BSR RP Candidate policy: None

BSR RP policy: None

Auto-RP Announce policy: None

Auto-RP Discovery policy: None

Anycast-RP 10.1.1.1 members:

192.168.1.1  192.168.2.2*

RP: 10.1.1.1*, (0), uptime: 02:46:54, expires: never,

priority: 0, RP-source: (local), group ranges:

224.0.0.0/4

Por ejemplo, recibe un mensaje de registro en uno de los routers que forma parte del conjunto RP. Este router agregará S,G para este origen en su tabla. Además, el router enviará un mensaje de registro PIM a todos los demás miembros del conjunto RP. La IP de origen de este mensaje de registro sería la dirección de este router que está en el conjunto RP, y el destino sería la dirección de cada router en el conjunto RP.

En este ejemplo, cuando el origen 172.16.1.1 envía el paquete multicast destinado a 239.1.1.1 a Nexus-1, Nexus-1 registra primero este origen como RP y envía un mensaje de registro a Nexus-2 para el origen 172.16.1.1 y el grupo 239.1.1.1. Cuando Nexus-2 recibe este registro, agrega entrada S,G para 172.16.1.1, 239.1.1.1 en la tabla mroute. Ahora tanto RP Nexus-1 como Nexus-2 conocen esta fuente. El mensaje de registro que se envió de Nexus-1 a Nexus-2 tenía IP de origen 192.168.1.1 e IP de destino 192.168.2.2 según se define en el conjunto RP.

Entradas Mroute en ambas casillas Nexus después del proceso de registro:

Nexus-1# sh ip mroute 239.1.1.1

IP Multicast Routing Table for VRF "default"

(172.16.1.1/32, 239.1.1.1/32), uptime: 00:00:22, ip pim

Incoming interface: Ethernet9/3, RPF nbr: 172.16.1.1, internal

Outgoing interface list: (count: 0)

Nexus-2# sh ip mroute 239.1.1.1

IP Multicast Routing Table for VRF "default"

(172.16.1.1/32, 239.1.1.1/32), uptime: 00:00:17, pim ip

Incoming interface: Ethernet9/2, RPF nbr: 10.7.7.1, internal

Outgoing interface list: (count: 0)

Volcado de paquetes de tal mensaje de registro tomado en Nexus-2:

Ethernet II, Src: d8:67:d9:04:5f:41 (d8:67:d9:04:5f:41), Dst: d8:67:d9:02:3b:41

(d8:67:d9:02:3b:41)

Destination: d8:67:d9:02:3b:41 (d8:67:d9:02:3b:41)

Address: d8:67:d9:02:3b:41 (d8:67:d9:02:3b:41)

.... ...0 .... .... .... .... = IG bit: Individual address (unicast)

.... ..0. .... .... .... .... = LG bit: Globally unique address (factory

default)

Source: d8:67:d9:04:5f:41 (d8:67:d9:04:5f:41)

Address: d8:67:d9:04:5f:41 (d8:67:d9:04:5f:41)

.... ...0 .... .... .... .... = IG bit: Individual address (unicast)

.... ..0. .... .... .... .... = LG bit: Globally unique address (factory

default)

Type: IP (0x0800)

Internet Protocol, Src: 192.168.1.1 (192.168.1.1), Dst: 192.168.2.2 (192.168.2.2)

Version: 4

Header length: 20 bytes

Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)

0000 00.. = Differentiated Services Codepoint: Default (0x00)

.... ..0. = ECN-Capable Transport (ECT): 0

.... ...0 = ECN-CE: 0

Total Length: 128

Identification: 0x1b27 (6951)

Flags: 0x00

0.. = Reserved bit: Not Set

.0. = Don't fragment: Not Set

..0 = More fragments: Not Set

Fragment offset: 0

Time to live: 254

Protocol: PIM (0x67)

Header checksum: 0x9aea [correct]

[Good: True]

[Bad : False]

Source: 192.168.1.1 (192.168.1.1)

Destination: 192.168.2.2 (192.168.2.2)

Protocol Independent Multicast

Version: 2

Type: Register (1)

Checksum: 0xdeff [correct]

PIM parameters

Flags: 0x00000000

0... .... .... .... .... .... .... .... = Not border

.0.. .... .... .... .... .... .... .... = Not Null-Register

Internet Protocol, Src: 172.16.1.1 (172.16.1.1), Dst: 239.1.1.1 (239.1.1.1)

Version: 4

Header length: 20 bytes

Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)

0000 00.. = Differentiated Services Codepoint: Default (0x00)

.... ..0. = ECN-Capable Transport (ECT): 0

.... ...0 = ECN-CE: 0

Total Length: 100

Identification: 0x0000 (0)

Flags: 0x00

0.. = Reserved bit: Not Set

.0. = Don't fragment: Not Set

..0 = More fragments: Not Set

Fragment offset: 0

Time to live: 254

Protocol: ICMP (0x01)

Header checksum: 0xa294 [correct]

[Good: True]

[Bad : False]

Source: 172.16.1.1 (172.16.1.1)

Destination: 239.1.1.1 (239.1.1.1)

Internet Control Message Protocol

Type: 8 (Echo (ping) request)

Code: 0 ()

Checksum: 0x9484 [correct]

Identifier: 0x0000

Sequence number: 0 (0x0000)

Data (72 bytes)

0000  00 00 00 00 00 71 e9 54 ab cd ab cd ab cd ab cd   .....q.T........

0010  ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd   ................

0020  ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd   ................

0030  ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd   ................

0040  ab cd ab cd ab cd ab cd                           ........

Data: 000000000071E954ABCDABCDABCDABCDABCDABCDABCDABCD...

[Length: 72]

Puede utilizar este filtro para capturar paquetes PIM en la banda del Nexus:

ethanalyzer local interface inband capture-filter "ip proto 103" limit-capture-frames 0 write logflash: pim.pcap

Esto comenzará a capturar paquetes PIM indefinidamente hasta que cntrl+c se presione. Los paquetes se muestran en la pantalla y se escribirían en el archivo pim.pcap en logflash. También puede incluir la dirección IP para capturar paquetes de un vecino PIM determinado ("ip proto 103 y host <ip_address>").

Depuraciones relevantes

Estas son las dos depuraciones que son útiles para verificar el proceso de registro en Nexus:

- debug ip pim data-register send

- debug ip pim data-register receive

Nexus-1

2012 Sep 20 12:25:52.537472 pim: [6405] (default-base) Received Register from 172.16.1.2 for (172.16.1.1/32, 239.1.1.1/32)

2012 Sep 20 12:25:52.537656 pim: [6405] (default-base) Create route for (172.16.1.1/32, 239.1.1.1/32)

2012 Sep 20 12:25:52.537716 pim: [6405] (default-base) Add route (172.16.1.1/32, 239.1.1.1/32) to MRIB, multi-route TRUE

2012 Sep 20 12:25:52.537745 pim: [6405] (default-base) RP 10.1.1.1 is an Anycast-RP

2012 Sep 20 12:25:52.537771 pim: [6405] (default-base) Forward Register to Anycast-RP member 192.168.2.2

2012 Sep 20 12:25:52.537825 pim: [6405] (default-base) Send Register-Stop to 172.16.1.2 for (172.16.1.1/32, 239.1.1.1/32)

2012 Sep 20 12:25:52.538591 pim: [6405] (default-base) Received Register-Stop from 10.1.1.1 for (172.16.1.1/32, 239.1.1.1/32)

Nexus-2

2012 Sep 20 12:26:36.367862 pim: [7189] (default-base) Received Register from 192.168.1.1 for (172.16.1.1/32, 239.1.1.1/32)

2012 Sep 20 12:26:36.368093 pim: [7189] (default-base) Create route for (172.16.1.1/32, 239.1.1.1/32)

2012 Sep 20 12:26:36.368175 pim: [7189] (default-base) Add route (172.16.1.1/32, 239.1.1.1/32) to MRIB, multi-route FALSE

2012 Sep 20 12:26:36.368223 pim: [7189] (default-base) RP 10.1.1.1 is an Anycast-RP

2012 Sep 20 12:26:36.368240 pim: [7189] (default-base) Register received from Anycast-RP member 192.168.1.1

Este RFC proporciona más información sobre el proceso de registro de PIM: http://tools.ietf.org/rfc/rfc4610.txt

Además, consulte Configuración de PIM y PIM6 para obtener más información.

Información Relacionada

- Soporte Técnico y Documentación - Cisco Systems