O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve as diferentes maneiras de configurar as possíveis maneiras de bloquear ou filtrar certos tráfegos multicast nos switches Nexus 7000/9000. Também pode ser usado para conservar recursos multicast. Um dos exemplos comuns é a implementação da operação Universal Plug and Play pela Microsoft, que usa o SSDP para se comunicar entre os servidores.
A Cisco recomenda que você saiba como o Any-Source Multicast (ASM) com o uso do modo PIM Sparse funciona na plataforma Nexus.
As informações neste documento são baseadas nestas versões de software e hardware:
Note: Os resultados podem variar se o software/hardware for diferente.
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos usados neste documento começam com uma configuração limpa (padrão). Se a rede estiver em produção, certifique-se de que você entendeu o impacto potencial de qualquer comando.
Aqui está a lista dos acrônimos usados:
RP - Ponto de encontro
FHR - roteador First Hop
LHR - Último roteador de salto
SRC - Fonte multicast
REC - Receptor multicast
PACL - port access-list
RACL - Routed access-list
SVI - Interface virtual comutada
ACL - Lista de controle de acesso
Vamos supor que:
O endereço IP do RP é 192.168.10.1
O endereço ip do SRC é 172.16.10.100/32
Grupo SSDP: 239.255.255.250/239.255.255.253
Agora, vamos discutir a configuração com base na função do dispositivo. Por exemplo, FHR, LHR, RP, etc.
1. Filtrar registro para o RP existente.
|
2. Filtrar o registro para o RP definindo um RP falso (que não existe (por exemplo, 1.1.1.1) para grupos SSDP; A FHR, neste caso, assume a função de RP.
|
Verifique:
|
A saída acima confirma que o FHR não está registrando o fluxo para RP.
3. Aplicando a política IGMP na SVI de entrada (onde a REC reside). A ideia aqui é filtrar os relatórios de associação IGMP para grupos SSDP do REC.
|
Verifique:
|
A saída acima confirma que o relatório de associação de IGMP é filtrado e (*,G) não é enviada para RP.
Você pode usar uma combinação das opções 1 ou 2 e 3, dependendo de seu requisito.
Por exemplo:
4. Filtrar registro para o RP existente (função FHR):
|
5. Política IGMP para filtrar relatórios de associação IGMP do REC (função LHR).
|
Verifique:
Quase igual à verificação feita nos pontos C e D.
|
6. Política de registro para bloquear o registro do grupo SSDP da FHR.
|
Verifique:
|
A saída acima confirma que o RP está bloqueando o registro para o grupo 239.255.255.250.
7. Aplicando a política Join-prune no RP - união pim (*,G) e (S,G) para grupos SSDP apenas.
|
Verifique:
|
A saída acima confirma (*,G) que a união PIM está bloqueada pelo RP.
Embora todas as opções discutidas nas seções A, B ou C; Impedir que a FHR, a LHR ou a FHR/LHR registrem o fluxo no RP ou impedir o envio da PIM Join (*,G) para o RP, respectivamente; uma entrada mroute ou snooping ainda pode ser criada e consumirá entradas HW multicast.
Note: Você pode usar RACL ou PACL em interfaces de entrada SVI ou Camada 2/canais de porta/canais de porta VPC caso o VPC esteja configurado. Se o SRC/REC for pulverizado em uma interface VLAN ou L2 diferente, isso também significa que o RACL ou o PACL precisarão ser aplicados em todos eles. Mas, dependendo do hardware/software (principalmente devido à limitação de hardware), os resultados podem variar.
Configure o PACL na porta de entrada da Camada 2 ou canal de porta ou canal de porta VPC para bloquear o tráfego SSDP ou a criação de entrada (S, G) no FHR.
Note: Dependendo do HW usado (exemplo Nexus N9000), o TCAM pode precisar ser gravado antes (o que requer recarregamento) da aplicação do PACL.
Por exemplo:
|
Verifique:
|
Como o tráfego multicast/portas de associação de IGMP estão bloqueadas via PACL, você não verá nenhuma entrada mroute e snooping. Essencialmente, o PACL está descartando ambos.
Você pode configurar o RACL no SVI de entrada onde o SRC existe, mas dependendo do SW/HW usado; (S, G) a entrada ainda pode ser criada ou o tráfego pode ser encaminhado para outras VLANs locais.
|
Verifique:
É praticamente igual ao PACL mas a opção RACL pode não fornecer os mesmos resultados que o PACL; principalmente, a limitação de HW é mencionada anteriormente também.
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
15-Sep-2021 |
Versão inicial |