Reflexão de serviço multicast usando PIM-SM no IOS-XE : Multicast para Unicast
Contents
Introdução
O objetivo deste artigo é fornecer uma compreensão do funcionamento básico do MSR (Multicast Service Replication) usando plataformas IOS-XE, através da forma de um guia de laboratório de configuração.
Pré-requisitos
Requisitos
Noções básicas sobre PIM-SM
Componentes Utilizados
ASR1000 (R2&R4), ISR4300 (R3), ISR2900 (R1&R5)
Configurar
Mostramos as configurações fim-a-fim abaixo com base no cenário diagramático abaixo para converter o multicast.
Diagrama de Rede
Configurações
No diagrama acima, o nó R1 atua como o receptor que deve receber apenas o feed de dados multicast unicast da origem multicast.
O nó R5 atua como a origem de multicast que gera o tráfego ICMP de multicast originado de sua interface de loopback 0.
O nó R2 está sob o domínio principal multicast dos provedores de conteúdo e está executando PIM-SM com base de OSPF.
O nó R3 atua como o roteador que executa o Multicast Service Replication Application e é, neste caso, o roteador de borda multicast a partir do qual o tráfego de dados multicast deve ser convertido em um pacote de dados unicast em direção ao receptor. Ele usa OSPF e EIGRP com o Provedor de conteúdo e ISP, respectivamente, e hospeda o RP (Ponto de reunião) em sua interface de loopback no domínio de núcleo multicast.
O nó R4 está sob o controle do núcleo do ISP e não está habilitado para multicast e entende apenas como acessar o nó R3 usando roteamento EIGRP subjacente.
Abaixo, você pode encontrar as configurações relevantes presentes nos nós presentes no diagrama de topologia acima:
R1:
!
no ip domain lookup
ip cef
no ipv6 cef
!
interface GigabitEthernet0/2
ip address 10.10.20.1 255.255.255.0
duplex auto
speed auto
end
!
router eigrp 100
network 10.10.20.0 0.0.0.255
!R2:
!
interface GigabitEthernet0/0/0
ip address 10.10.20.2 255.255.255.0
negotiation auto
!
interface GigabitEthernet0/0/2
ip address 10.10.10.1 255.255.255.0
negotiation auto
!
router eigrp 100
network 10.10.10.0 0.0.0.255
network 10.10.20.0 0.0.0.255
!R3:
!
ip multicast-routing distributed
!
interface Loopback0
ip address 192.168.2.1 255.255.255.255
ip pim sparse-mode
ip ospf 1 area 0
!
interface GigabitEthernet0/0/0
ip address 192.168.30.1 255.255.255.0
ip pim sparse-mode
ip ospf 1 area 0
negotiation auto
!
interface GigabitEthernet0/0/1
ip address 10.10.10.2 255.255.255.0
negotiation auto
!
interface Vif1
ip address 192.169.169.1 255.255.255.0
ip pim sparse-mode
ip service reflect GigabitEthernet0/0/0 destination 224.1.1.0 to 10.10.20.0 mask-len 24 source 192.169.169.169 <<<<
ip igmp static-group 224.1.1.1
ip ospf 1 area 0
!
router eigrp 100
network 10.10.10.0 0.0.0.255
!
router ospf 1
!
ip pim rp-address 192.168.2.1
!R4:
!
ip multicast-routing distributed
!
interface GigabitEthernet0/0/0
ip address 192.168.30.2 255.255.255.0
ip pim sparse-mode
ip ospf 1 area 0
negotiation auto
!
interface GigabitEthernet0/0/2
ip address 192.168.20.1 255.255.255.0
ip pim sparse-mode
ip ospf 1 area 0
negotiation auto
!
router ospf 1
!
ip pim rp-address 192.168.2.1
!R5:
!
ip multicast-routing
ip cef
no ipv6 cef
!
interface Loopback0
ip address 192.168.168.168 255.255.255.255
ip pim sparse-mode
ip ospf 1 area 0
!
interface GigabitEthernet0/2
ip address 192.168.20.2 255.255.255.0
ip pim sparse-mode
ip ospf 1 area 0
duplex auto
speed auto
!
router ospf 1
!
ip pim rp-address 192.168.2.1
!Verificar
Podemos validar as configurações executando um ping de teste para simular o tráfego multicast do roteador R5 com uma origem de sua interface de loopback 0 [192.168.168.168] destinada ao endereço multicast 224.1.1.1. Em seguida, verifique as entradas mroute no nó que está executando o aplicativo MSR, ou seja, R3 :
R5(config)#do ping 224.1.1.1 sou lo 0 rep 10000000
Type escape sequence to abort.
Sending 10000000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.168.168
.............................R3#sh ip mroute 224.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group, c - PFP-SA cache created entry
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.1.1.1), 00:47:41/stopped, RP 192.168.2.1, flags: SJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Vif1, Forward/Sparse, 00:46:36/00:01:23 <<<<
(192.168.168.168, 224.1.1.1), 00:00:20/00:02:43, flags: T
Incoming interface: GigabitEthernet0/0/0, RPF nbr 192.168.30.2
Outgoing interface list:
Vif1, Forward/Sparse, 00:00:20/00:02:39 <<<<R3#sh ip mroute 224.1.1.1 count
Use "show ip mfib count" to get better response time for a large number of mroutes.
IP Multicast Statistics
3 routes using 2938 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 224.1.1.1, Source count: 1, Packets forwarded: 1455, Packets received: 1458 <<<<
RP-tree: Forwarding: 1/0/100/0, Other: 1/0/0
Source: 192.168.168.168/32, Forwarding: 1454/1/113/0, Other: 1457/3/0
R3#sh ip mroute 224.1.1.1 count
Use "show ip mfib count" to get better response time for a large number of mroutes.
IP Multicast Statistics
3 routes using 2938 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 224.1.1.1, Source count: 1, Packets forwarded: 1465, Packets received: 1468 <<<<
RP-tree: Forwarding: 1/0/100/0, Other: 1/0/0
Source: 192.168.168.168/32, Forwarding: 1464/1/113/0, Other: 1467/3/0Além disso, você pode fazer capturas para verificar se os pacotes estão realmente sendo convertidos para o endereço de destino unicast pretendido no nó R2 usando o recurso EPC (Embedded Packet Capture) no roteador IOS-XE :
R2#mon cap TAC int gi 0/0/2 both match any
R2#mon cap TAC buff siz 50 circular
R2#mon cap TAC start
Started capture point : TAC
R2#
*Aug 12 06:50:40.195: %BUFCAP-6-ENABLE: Capture Point TAC enabled.
R2#sh mon cap TAC buff br | i ICMP
6 114 10.684022 192.169.169.169 -> 10.10.20.1 0 BE ICMP <<<<
7 114 10.684022 192.169.169.169 -> 10.10.20.1 0 BE ICMP <<<<
8 114 12.683015 192.169.169.169 -> 10.10.20.1 0 BE ICMP <<<<
9 114 12.683015 192.169.169.169 -> 10.10.20.1 0 BE ICMP <<<<Aqui, o ponto importante a observar é que regularmente, quando você executa pings ICMP multicast em "ambientes de laboratório", normalmente espera receber de volta os pacotes de resposta de eco ICMP do lado do receptor em direção à origem, supondo que haja acessibilidade completa entre os dois (origem e receptor). No entanto, neste cenário, é importante observar que, mesmo se tentarmos anunciar o endereço de origem NATted para os pacotes ICMP multicast, ou seja, 192.169.169.169 até o receptor, ou seja, R1 através do EIGRP, as respostas de eco ICMP unicast não cruzarão o roteador R3, já que o NAT reverso não está configurado no nó do aplicativo MSR. Podemos testar isso, tentando executar o anúncio de rota EIGRP da interface Vif 1 em R3 no EIGRP (roteamento do núcleo do ISP):
ISR4351(config)#router eigrp 100
ISR4351(config-router)#network 192.169.169.0 0.0.0.255 <<<<Agora, podemos verificar as capturas feitas no nó R2 nas respostas de eco ICMP sendo enviadas para R3:
R2#sh mon cap TAC buff br | i ICMP
249 114 317.847948 192.169.169.169 -> 10.10.20.1 0 BE ICMP
250 114 317.847948 192.169.169.169 -> 10.10.20.1 0 BE ICMP
251 114 317.847948 10.10.20.1 -> 192.169.169.169 0 BE ICMP <<<<
252 114 317.847948 10.10.20.1 -> 192.169.169.169 0 BE ICMP <<<<
253 114 319.847948 192.169.169.169 -> 10.10.20.1 0 BE ICMP
254 114 319.847948 192.169.169.169 -> 10.10.20.1 0 BE ICMP
255 114 319.848955 10.10.20.1 -> 192.169.169.169 0 BE ICMP <<<<
256 114 319.848955 10.10.20.1 -> 192.169.169.169 0 BE ICMP <<<<
259 114 321.848955 192.169.169.169 -> 10.10.20.1 0 BE ICMP
260 114 321.848955 192.169.169.169 -> 10.10.20.1 0 BE ICMP
261 114 321.848955 10.10.20.1 -> 192.169.169.169 0 BE ICMP <<<<
262 114 321.848955 10.10.20.1 -> 192.169.169.169 0 BE ICMP <<<< Mas os pings ainda falharão como visto na origem R5:
R5(config)#do ping 224.1.1.1 sou lo 0 rep 10000000
Type escape sequence to abort.
Sending 10000000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.168.168
......................................................................
......................................................................
Agora, para que as respostas cheguem até a origem, podemos configurar o encaminhamento de porta NAT no nó de aplicativo MSR R3 para converter o tráfego destinado para 192.169.169.169 a 192.168.168.168, configurando o NAT extensível :
R3(config)#int gi 0/0/1
R3(config-if)#ip nat out
R3(config-if)#int gi 0/0/0
R3(config-if)#ip nat ins
R3(config-if)#exit
R3(config)#ip nat inside source static 192.168.168.168 192.169.169.169 extendable <<<<Agora, ao verificar o nó R5 de origem, podemos ver a resposta voltar :
R5(config)#do ping 224.1.1.1 sou lo 0 rep 10000000
Type escape sequence to abort.
Sending 10000000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.168.168
......................................................................
Reply to request 716 from 10.10.20.1, 1 ms
Reply to request 716 from 10.10.20.1, 1 ms
Reply to request 717 from 10.10.20.1, 1 ms
Reply to request 717 from 10.10.20.1, 1 ms
Reply to request 718 from 10.10.20.1, 1 ms
Reply to request 718 from 10.10.20.1, 1 ms O procedimento acima foi apenas executado para explicar o fluxo de pacotes e para entender como estabelecer o caminho/fluxo unicast reverso para o tráfego de dados e o tráfego multicast downstream. Como no cenário de produção regular, você normalmente não se depara com casos/instâncias em que os aplicativos multicast em execução no servidor/origem exigem pacotes de confirmação inversa dos receptores em formato unicast.
Pelos testes e validações acima, ele deve ter fornecido uma breve visão geral de como executar o aplicativo de replicação de serviço multicast em um dos nós de borda multicast e como implantar o mesmo se o mesmo mostrado acima fosse expandido para uma implantação em larga escala.
Feedback