{"id":33142,"date":"2019-10-31T21:50:58","date_gmt":"2019-10-31T18:50:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/printsipy-raboty-protokola-pim\/"},"modified":"2019-10-31T21:50:58","modified_gmt":"2019-10-31T18:50:58","slug":"printsipy-raboty-protokola-pim","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/printsipy-raboty-protokola-pim","title":{"rendered":"Princ\u00edpios de funcionamento do protocolo PIM","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>O Protocolo PIM \u00e9 um conjunto de protocolos para a transmiss\u00e3o de multicast em redes entre roteadores. As rela\u00e7\u00f5es de vizinhan\u00e7a s\u00e3o estabelecidas de forma semelhante \u00e0 dos protocolos de roteamento din\u00e2mico. O PIMv2 envia mensagens Hello a cada 30 segundos para o endere\u00e7o multicast reservado 224.0.0.13 (Todos os Roteadores PIM). A mensagem cont\u00e9m Hold Timers \u2014 geralmente igual a 3,5 vezes o Hello Timer, ou seja, 105 segundos por padr\u00e3o.<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/AqjQmPR.jpg\"><img decoding=\"async\" alt=\"Princ\u00edpios de funcionamento do protocolo PIM\" src=\"\/wp-content\/uploads\/2019\/05\/f2e0c7dbdb8d7640671440289fbcd91f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\n O PIM utiliza dois modos principais de opera\u00e7\u00e3o \u2014 Modo Denso e Modo Ralo. Comecemos pelo Modo Denso. <noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\n<b>\u00c1rvores de Distribui\u00e7\u00e3o Baseadas em Fonte.<\/b><br \/>\nO modo Denso \u00e9 adequado para situa\u00e7\u00f5es com um grande n\u00famero de clientes em diversos grupos multicast. Quando um roteador recebe tr\u00e1fego multicast, ele primeiro verifica a regra RPF. A RPF \u00e9 uma regra usada para verificar a origem do multicast com a tabela de roteamento unicast. \u00c9 necess\u00e1rio que o tr\u00e1fego chegue \u00e0 interface correspondente ao host de acordo com a tabela de roteamento unicast. Este mecanismo resolve o problema de loops durante a transmiss\u00e3o de multicast.<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/RE54lnP.png\"><img decoding=\"async\" alt=\"Princ\u00edpios de funcionamento do protocolo PIM\" src=\"\/wp-content\/uploads\/2019\/05\/4d855ea59c6329c7e727cc70a79367b2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nO R3, a partir da mensagem multicast, descobre a origem do multicast (Source IP) e verifica dois fluxos provenientes de R1 e R2 na sua tabela unicast. O fluxo da interface indicada pela tabela (R1 para R3) ser\u00e1 transmitido, enquanto o fluxo de R2 ser\u00e1 descartado, pois para chegar \u00e0 origem do multicast, \u00e9 necess\u00e1rio enviar pacotes pela S0\/1.<br \/>\nA pergunta \u00e9 o que acontece se voc\u00ea tiver duas rotas equivalentes com a mesma m\u00e9trica? Nesse caso, o roteador escolher\u00e1 com base no next-hop dessas rotas. Aquele com o IP mais alto \u00e9 o ganhador. Se for necess\u00e1rio alterar esse comportamento, pode-se usar ECMP. Mais detalhes <noindex><a rel=\"nofollow\" href=\"https:\/\/drive.google.com\/file\/d\/1yiam4-OwlDoXrfdfdienMN_nQaOJGi29\/view?usp=sharing\">aqui<\/a><\/noindex>.<br \/>\nAp\u00f3s verificar a regra RPF, o roteador envia o pacote multicast a todos os seus vizinhos PIM, exceto \u00e0quele de onde o pacote foi recebido. Os demais roteadores PIM repetem esse processo. O caminho que o pacote multicast percorre da fonte at\u00e9 os destinat\u00e1rios finais forma uma \u00e1rvore, chamada de \u00e1rvore de distribui\u00e7\u00e3o baseada em fonte, \u00e1rvore de caminho mais curto (SPT), \u00e1rvore de origem. Tr\u00eas nomes diferentes, escolha qualquer um.<br \/>\nComo resolver a quest\u00e3o de que alguns roteadores n\u00e3o desejam um determinado fluxo multicast e para os quais n\u00e3o h\u00e1 destinat\u00e1rio, mas o roteador ascendente ainda o envia. Para isso, foi desenvolvido o mecanismo Prune. <br \/>\n<b>Mensagem Prune.<\/b><br \/>\nPor exemplo, o R2 continuar\u00e1 enviando multicast para o R3, embora o R3, seguindo a regra RPF, o descarte. Para que sobrecarregar o canal? O R3 envia uma Mensagem PIM Prune e o R2, ao receber esta mensagem, remover\u00e1 a interface S0\/1 da lista (outgoing interface list) para este fluxo, a lista de interfaces das quais deve enviar este tr\u00e1fego. <\/p>\n<blockquote><p>A seguir, uma defini\u00e7\u00e3o mais formal de uma mensagem PIM Prune:<br \/>\nA mensagem PIM Prune \u00e9 enviada por um roteador a um segundo roteador para fazer com que o segundo roteador remova o link onde o Prune \u00e9 recebido de uma SPT (S,G) espec\u00edfica.<\/p><\/blockquote>\n<p>\nAp\u00f3s receber a mensagem Prune, o R2 configura o timer de Prune para 3 minutos. Ap\u00f3s tr\u00eas minutos, ele come\u00e7ar\u00e1 a enviar tr\u00e1fego novamente, at\u00e9 receber outra mensagem Prune. Isso ocorre no PIMv1.<br \/>\nNo PIMv2, foi adicionado um timer de State Refresh (por padr\u00e3o 60 segundos). Assim que uma mensagem Prune \u00e9 enviada pelo R3, esse timer \u00e9 acionado no R3. Ao final deste timer, o R3 enviar\u00e1 uma mensagem de State Refresh, que ir\u00e1 redefinir o timer de Prune de 3 minutos no R2 para este grupo. <br \/>\nRaz\u00f5es para enviar a mensagem Prune:<\/p>\n<ul>\n<li> Quando um pacote multicast n\u00e3o passou na verifica\u00e7\u00e3o RPF.<\/li>\n<li> Quando n\u00e3o h\u00e1 clientes conectados localmente que solicitaram o grupo multicast (IGMP Join) e n\u00e3o h\u00e1 vizinhos PIM para quem enviar o tr\u00e1fego multicast (Non-prune Interface).<\/li>\n<\/ul>\n<p>\n<b>Mensagem Graft.<\/b><br \/>\nVamos imaginar que o R3 n\u00e3o quis tr\u00e1fego do R2, enviou Prune e recebeu multicast do R1. Mas, de repente, a conex\u00e3o entre R1-R3 falhou e o R3 ficou sem multicast. Podemos esperar 3 minutos at\u00e9 que o Timer de Prune no R2 expire. Esperar 3 minutos \u00e9 muito tempo; para n\u00e3o esperar, \u00e9 necess\u00e1rio enviar uma mensagem que imediatamente retire a interface S0\/1 no R2 do estado podado. Esta mensagem ser\u00e1 a mensagem Graft. Ap\u00f3s receber a mensagem Graft, o R2 enviar\u00e1 em resposta um Graft-ACK.<br \/>\n<b>Prune Override.<\/b><br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/zfo0Dx5.png\"><img decoding=\"async\" alt=\"Princ\u00edpios de funcionamento do protocolo PIM\" src=\"\/wp-content\/uploads\/2019\/05\/72e368905d2e37ba9b9d46101ebcd8ae.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nVamos analisar este esquema. R1 transmite multicast para o segmento com dois roteadores. R3 recebe e transmite o tr\u00e1fego, R2 recebe, mas n\u00e3o h\u00e1 ningu\u00e9m para transmitir o tr\u00e1fego. Ele envia uma mensagem Prune para R1 neste segmento. R1 deve remover Fa0\/0 da lista e parar de transmitir para este segmento, mas o que acontecer\u00e1 com R3? R3 est\u00e1 no mesmo segmento, tamb\u00e9m recebeu essa mensagem Prune e entendeu a trag\u00e9dia da situa\u00e7\u00e3o. Antes que R1 pare de transmitir, ele configura um timer de 3 segundos e vai parar de transmitir em 3 segundos. S\u00e3o exatamente 3 segundos que R3 tem para n\u00e3o perder seu multicast. Portanto, R3, o mais r\u00e1pido poss\u00edvel, envia uma mensagem Pim Join para este grupo e R1 j\u00e1 n\u00e3o pensa mais em parar de transmitir. Sobre as mensagens Join abaixo.<br \/>\n<b>Mensagem Assert.<\/b><br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/rliwmNF.png\"><img decoding=\"async\" alt=\"Princ\u00edpios de funcionamento do protocolo PIM\" src=\"\/wp-content\/uploads\/2019\/05\/f7cc9c247cd26a8f9567b170f9b61bbb.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nImaginemos a seguinte situa\u00e7\u00e3o: dois roteadores transmitem simultaneamente em uma rede. Ambos recebem o mesmo fluxo de uma fonte e ambos o transmitem em uma rede atrav\u00e9s da interface e0. Portanto, eles precisam determinar quem ser\u00e1 o \u00fanico transmissor para esta rede. Para isso, s\u00e3o utilizadas mensagens Assert. Quando R2 e R3 detectam a duplica\u00e7\u00e3o do tr\u00e1fego multicast, ou seja, quando R2 e R3 recebem o multicast que eles mesmos est\u00e3o transmitindo, os roteadores entendem que algo n\u00e3o est\u00e1 certo. Nesse caso, eles enviam mensagens Assert, que incluem a Dist\u00e2ncia Administrativa e a m\u00e9trica da rota atrav\u00e9s da qual a fonte multicast \u00e9 alcan\u00e7ada \u2014 10.1.1.10. O vencedor \u00e9 determinado assim:<\/p>\n<ol>\n<li>Aquele com a AD mais baixa.<\/li>\n<li>Se a AD for igual, verifica-se quem tem a m\u00e9trica mais baixa.<\/li>\n<li>Se ainda estiver igual, \u00e9 aquele que tiver o IP mais alto na rede para a qual eles transmitem este multicast.<\/li>\n<\/ol>\n<p>\nO vencedor nesta vota\u00e7\u00e3o, o roteador se torna o Roteador Designado. Para escolher o DR, tamb\u00e9m s\u00e3o utilizados os Pim Hello. No in\u00edcio do artigo, foi exibida uma mensagem PIM Hello, onde pode-se notar o campo DR. Vence aquele que tiver o endere\u00e7o IP mais alto nesta conex\u00e3o.<br \/>\nTabela \u00fatil:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/Et1kP7h.png\"><img decoding=\"async\" alt=\"Princ\u00edpios de funcionamento do protocolo PIM\" src=\"\/wp-content\/uploads\/2019\/05\/d450c9fac2b6d74c5b7414d85910bca4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\n<b>Tabela MROUTE.<\/b><br \/>\nAp\u00f3s a considera\u00e7\u00e3o inicial do funcionamento do protocolo PIM, precisamos entender como trabalhar com a tabela de roteamento multicast. A tabela mroute armazena informa\u00e7\u00f5es sobre quais fluxos foram solicitados pelos clientes e quais fluxos est\u00e3o sendo transmitidos pelos servidores multicast. <br \/>\nPor exemplo, ao receber um IGMP Membership Report ou PIM Join em alguma interface, uma entrada do tipo (*, G) \u00e9 adicionada \u00e0 tabela de roteamento:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/ufXsgnR.jpg\"><img decoding=\"async\" alt=\"Princ\u00edpios de funcionamento do protocolo PIM\" src=\"\/wp-content\/uploads\/2019\/05\/094d96f36512c3b1b8d179044f354ac1.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nEsta entrada indica que uma solicita\u00e7\u00e3o de tr\u00e1fego foi recebida do endere\u00e7o 238.38.38.38. A flag DC significa que o multicast funcionar\u00e1 em modo Dense e C indica que o receptor est\u00e1 diretamente conectado ao roteador, ou seja, o roteador recebeu um IGMP Membership Report e um PIM Join.<br \/>\nSe houver uma entrada do tipo (S,G), isso significa que temos um fluxo multicast:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/QJCZZwf.jpg\"><img decoding=\"async\" alt=\"Princ\u00edpios de funcionamento do protocolo PIM\" src=\"\/wp-content\/uploads\/2019\/05\/56f2e8376a7f89f3fd3082a098ce42e5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nNo campo S \u2014 192.168.1.11, temos o endere\u00e7o IP da fonte do multicast, que ser\u00e1 verificado pela regra RPF. Em caso de problemas, devemos primeiro verificar a tabela unicast para o caminho at\u00e9 a fonte. O campo Incoming Interface indica a interface pela qual o multicast chega. Na tabela de roteamento unicast, o caminho at\u00e9 a fonte deve referenciar a interface indicada aqui. No campo Outgoing Interface, \u00e9 indicado para onde o multicast ser\u00e1 redirecionado. Se estiver vazio, significa que o roteador n\u00e3o recebeu solicita\u00e7\u00f5es para esse tr\u00e1fego. Informa\u00e7\u00f5es mais detalhadas sobre todas as flags podem ser encontradas. <noindex><a rel=\"nofollow\" href=\"https:\/\/drive.google.com\/file\/d\/1ArBLFJdyN8tCangB5GL2JaS47FEZaad-\/view?usp=sharing\">aqui<\/a><\/noindex>.<br \/>\n<b>PIM Sparse-mode.<\/b><br \/>\nA estrat\u00e9gia Sparse-mode \u00e9 oposta \u00e0 Dense-mode. Quando o Sparse-mode recebe tr\u00e1fego multicast, ele s\u00f3 enviar\u00e1 o tr\u00e1fego atrav\u00e9s das interfaces onde houve solicita\u00e7\u00f5es para esse fluxo, como mensagens Pim Join ou IGMP Report solicitando esse tr\u00e1fego.<br \/>\nElementos semelhantes entre SM e DM:<\/p>\n<ul>\n<li> As rela\u00e7\u00f5es de vizinhan\u00e7a s\u00e3o estabelecidas da mesma forma que no PIM DM.<\/li>\n<li> A regra RPF funciona.<\/li>\n<li> A escolha do DR \u00e9 semelhante.<\/li>\n<li> O mecanismo Prune Overrides e as mensagens Assert s\u00e3o an\u00e1logas.<\/li>\n<\/ul>\n<p>\nPara controlar quem, onde e que tr\u00e1fego multicast \u00e9 necess\u00e1rio na rede, \u00e9 necess\u00e1rio um centro de informa\u00e7\u00f5es comum. Esse centro ser\u00e1 o Rendezvous Point (RP). Todos que desejam algum tr\u00e1fego multicast ou que come\u00e7aram a receber tr\u00e1fego multicast de uma fonte enviam suas solicita\u00e7\u00f5es ao RP.<br \/>\nQuando o RP receber tr\u00e1fego multicast, ele o enviar\u00e1 para os roteadores que solicitaram anteriormente esse tr\u00e1fego. <br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/5AErtbS.jpg\"><img decoding=\"async\" alt=\"Princ\u00edpios de funcionamento do protocolo PIM\" src=\"\/wp-content\/uploads\/2019\/05\/35646434f8b80a8a05253111864de2da.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nVamos imaginar uma topologia onde o RP \u00e9 R3. Assim que R1 receber tr\u00e1fego de S1, ele encapsular\u00e1 este pacote multicast em uma mensagem unicast PIM Register e enviar\u00e1 para o RP. Como ele sabe quem \u00e9 o RP? Nesse caso, ele est\u00e1 configurado estaticamente, e falaremos sobre a configura\u00e7\u00e3o din\u00e2mica do RP mais tarde. <\/p>\n<blockquote><p>ip pim rp-address 3.3.3.3<\/p><\/blockquote>\n<p>\nO RP verificar\u00e1 se houve informa\u00e7\u00f5es de algu\u00e9m que desejasse receber esse tr\u00e1fego? Suponhamos que n\u00e3o. Ent\u00e3o, o RP enviar\u00e1 uma mensagem PIM Register-Stop para o R1, o que significa que ningu\u00e9m precisa desse multicast, a inscri\u00e7\u00e3o foi negada. O R1 n\u00e3o enviar\u00e1 o multicast. Mas a fonte do multicast enviar\u00e1, ent\u00e3o, ap\u00f3s receber o Register-Stop, o R1 iniciar\u00e1 um temporizador Register-Suppression de 60 segundos. Quinze segundos antes do final desse temporizador, o R1 enviar\u00e1 uma mensagem Register em branco com o bit Null-Register (ou seja, sem pacote multicast encapsulado) em dire\u00e7\u00e3o ao RP. O RP, por sua vez, agir\u00e1 da seguinte forma:<\/p>\n<ul>\n<li> Se n\u00e3o houve destinat\u00e1rios, ele responder\u00e1 com uma mensagem Register-Stop.<\/li>\n<li> Se surgirem destinat\u00e1rios, ele n\u00e3o responder\u00e1 a ela. O R1, n\u00e3o recebendo uma negativa \u00e0 sua inscri\u00e7\u00e3o dentro de 5 segundos, ficar\u00e1 feliz e enviar\u00e1 uma mensagem Register com multicast encapsulado para o RP.<\/li>\n<\/ul>\n<p>\nComo o multicast chega ao RP parece estar claro, agora tentaremos responder \u00e0 pergunta de como o RP leva o tr\u00e1fego at\u00e9 os destinat\u00e1rios. Aqui precisamos introduzir um novo conceito \u2014 a \u00e1rvore de caminho raiz (root-path tree, RPT). A RPT \u00e9 uma \u00e1rvore com raiz no RP, crescendo em dire\u00e7\u00e3o aos destinat\u00e1rios, ramificando-se em cada roteador PIM-SM. O RP a cria ao receber mensagens PIM Join e adiciona um novo ramo \u00e0 \u00e1rvore. E assim, faz cada roteador inferior. A regra geral \u00e9 a seguinte:<\/p>\n<ul>\n<li> Quando um roteador PIM-SM recebe uma mensagem PIM Join em alguma interface, exceto na interface onde est\u00e1 o RP, ele adiciona um novo ramo \u00e0 \u00e1rvore.<\/li>\n<li> Um ramo tamb\u00e9m \u00e9 adicionado quando um roteador PIM-SM recebe um IGMP Membership Report de um host diretamente conectado. <\/li>\n<\/ul>\n<p>\nSuponhamos que temos um cliente multicast no roteador R5 para o grupo 228.8.8.8. Assim que o R5 receber o IGMP Membership Report do host, o R5 enviar\u00e1 um PIM Join em dire\u00e7\u00e3o ao RP e adicionar\u00e1 \u00e0 \u00e1rvore a interface voltada para o host. Ent\u00e3o, o R4 receber\u00e1 o PIM Join do R5, adicionar\u00e1 a interface Gi0\/1 \u00e0 \u00e1rvore e enviar\u00e1 o PIM Join em dire\u00e7\u00e3o ao RP. Por fim, o RP (R3) receber\u00e1 o PIM Join e adicionar\u00e1 Gi0\/0 \u00e0 \u00e1rvore. Assim, a inscri\u00e7\u00e3o do destinat\u00e1rio multicast \u00e9 realizada. Formamos uma \u00e1rvore com a raiz R3-Gi0\/0 \u2192 R4-Gi0\/1 \u2192 R5-Gi0\/0.<br \/>\nAp\u00f3s isso, um PIM Join ser\u00e1 enviado ao R1 e o R1 come\u00e7ar\u00e1 a enviar tr\u00e1fego multicast. \u00c9 importante notar que, se o host solicitar tr\u00e1fego antes do in\u00edcio da transmiss\u00e3o multicast, o RP n\u00e3o enviar\u00e1 o PIM Join e, de fato, n\u00e3o enviar\u00e1 nada para o R1.<br \/>\nSe, durante o envio do multicast, o host parar de querer receb\u00ea-lo, assim que o RP receber um PIM Prune na interface Gi0\/0, ele imediatamente enviar\u00e1 um PIM Register-Stop diretamente para o R1 e, em seguida, a mensagem PIM Prune atrav\u00e9s da interface Gi0\/1. O PIM Register-stop \u00e9 enviado via unicast para o endere\u00e7o de onde o PIM Register foi recebido.<br \/>\nComo mencionamos anteriormente, assim que o roteador envia um PIM Join para outro, por exemplo, R5 para R4, uma entrada ser\u00e1 adicionada no R4:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/msZjbr8.jpg\"><img decoding=\"async\" alt=\"Princ\u00edpios de funcionamento do protocolo PIM\" src=\"\/wp-content\/uploads\/2019\/05\/d1d621bee37e4b912a672690c581617a.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nE um temporizador \u00e9 iniciado, que deve ser constantemente resetado pelo R5 atrav\u00e9s do envio de mensagens PIM Join; caso contr\u00e1rio, o R4 o excluir\u00e1 da lista de sa\u00edda. O R5 enviar\u00e1 mensagens PIM Join a cada 60 segundos.<br \/>\n<b>Mudan\u00e7a do Shortest-Path Tree.<\/b><br \/>\nAdicionaremos uma interface entre o R1 e o R5 e veremos como o tr\u00e1fego fluir\u00e1 com essa topologia. <br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/wLKEyyg.jpg\"><img decoding=\"async\" alt=\"Princ\u00edpios de funcionamento do protocolo PIM\" src=\"\/wp-content\/uploads\/2019\/05\/4b15057a1d30f3b2d6246b8f3b6263eb.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nSuponha que o tr\u00e1fego foi enviado e recebido pelo antigo esquema R1-R2-R3-R4-R5, e agora conectamos e configuramos a interface entre o R1 e o R5.<br \/>\nPrimeiro, a tabela de roteamento unicast no R5 ser\u00e1 reorganizada, e agora a rede 192.168.1.0\/24 ser\u00e1 alcan\u00e7ada atrav\u00e9s da interface R5 Gi0\/2. Agora, ao receber multicast na interface Gi0\/1, o R5 entende que a regra RPF n\u00e3o est\u00e1 sendo satisfeita e que seria mais l\u00f3gico receber o multicast na Gi0\/2. Ele deve se desconectar do RPT e construir uma \u00e1rvore mais curta, chamada Shortest-Path Tree (SPT). Para isso, ele envia um PIM Join ao R1 pela Gi0\/2 e o R1 come\u00e7a a enviar multicast tamb\u00e9m pela Gi0\/2. Agora, o R5 precisa cancelar sua subscri\u00e7\u00e3o do RPT, para n\u00e3o receber duas c\u00f3pias. Para isso, ele envia uma mensagem Prune, indicando o endere\u00e7o IP da fonte e inserindo um bit especial \u2014 RPT-bit. Isso significa que n\u00e3o \u00e9 necess\u00e1rio me enviar tr\u00e1fego, pois eu aqui tenho uma \u00e1rvore melhor. O RP tamb\u00e9m envia mensagens PIM Prune em dire\u00e7\u00e3o ao R1, mas n\u00e3o envia a mensagem Register-Stop. Outra caracter\u00edstica: o R5 agora enviar\u00e1 continuamente PIM Prune para o RP, j\u00e1 que o R1 continua enviando PIM Register para o RP a cada minuto. O RP, enquanto n\u00e3o houver novos interessados nesse tr\u00e1fego, responder\u00e1 com uma recusa. O R5 informa ao RP que continua recebendo multicast atrav\u00e9s do SPT.<br \/>\n<b>Busca din\u00e2mica de RP. <br \/>\nAuto-RP.<\/b><br \/>\nEsta tecnologia \u00e9 propriet\u00e1ria da Cisco e n\u00e3o \u00e9 muito popular, mas ainda est\u00e1 em uso. A opera\u00e7\u00e3o do Auto-RP consiste em duas etapas principais:<br \/>\n1) O RP envia mensagens RP-Announce para o endere\u00e7o reservado \u2014 224.0.1.39, declarando-se RP, seja para todos ou para grupos espec\u00edficos. Esta mensagem \u00e9 enviada a cada minuto.<br \/>\n2) Um agente de mapeamento RP \u00e9 necess\u00e1rio, que ir\u00e1 enviar mensagens RP-Discovery indicando para quais grupos determinado RP deve ser ouvido. \u00c9 a partir desta mensagem que os roteadores PIM comuns ir\u00e3o determinar seu RP. O Mapping Agent pode ser tanto o pr\u00f3prio roteador RP quanto um roteador PIM separado. O RP-Discovery \u00e9 enviado para o endere\u00e7o 224.0.1.40 com um timer de um minuto.<br \/>\nVamos analisar o processo com mais detalhes:<br \/>\nVamos configurar o R3 como RP:<\/p>\n<blockquote><p>ip pim send-rp-announce loopback 0 scope 10<\/p><\/blockquote>\n<p>\nR2 como agente de mapeamento:<\/p>\n<blockquote><p>ip pim send-rp-discovery loopback 0 scope 10<\/p><\/blockquote>\n<p>\nE em todos os outros, vamos aguardar o RP atrav\u00e9s do Auto-RP:<\/p>\n<blockquote><p>ip pim autorp listener<\/p><\/blockquote>\n<p>\nAssim que configurarmos o R3, ele come\u00e7ar\u00e1 a enviar RP-Announce:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/6c4WucN.jpg\"><img decoding=\"async\" alt=\"Princ\u00edpios de funcionamento do protocolo PIM\" src=\"\/wp-content\/uploads\/2019\/05\/3077778bb47731bb02a8e7fc6945aa63.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nE o R2, ap\u00f3s a configura\u00e7\u00e3o como agente de mapeamento, come\u00e7ar\u00e1 a aguardar as mensagens RP-Announce. Somente quando encontrar pelo menos um RP, come\u00e7ar\u00e1 a enviar RP-Discovery:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/lw2JuDD.jpg\"><img decoding=\"async\" alt=\"Princ\u00edpios de funcionamento do protocolo PIM\" src=\"\/wp-content\/uploads\/2019\/05\/37eff65f3c359cd3091c47af22220a6b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nDessa forma, assim que os roteadores comuns (PIM RP Listener) receberem esta mensagem, eles saber\u00e3o onde procurar o RP.<br \/>\nUm dos principais problemas do Auto-RP \u00e9 que, para receber mensagens RP-Announce e RP-Discovery, \u00e9 necess\u00e1rio enviar um PIM Join para os endere\u00e7os 224.0.1.39-40, mas, para enviar, \u00e9 preciso saber onde est\u00e1 o RP. \u00c9 o cl\u00e1ssico problema do ovo e da galinha. Para resolver esse problema, foi inventado o modo PIM Sparse-Dense-Mode. Se o roteador n\u00e3o conhece o RP, ele opera no modo Dense-mode; se conhece, no modo Sparse-mode. Quando as interfaces dos roteadores normais est\u00e3o configuradas para PIM Sparse-mode e o comando ip pim autorp listener, o roteador operar\u00e1 no modo Dense-mode apenas para o multicast diretamente do protocolo Auto-RP (224.0.1.39-40).<br \/>\n<b>BootStrap Router (BSR).<\/b><br \/>\nEsta fun\u00e7\u00e3o opera de forma semelhante ao Auto-RP. Cada RP envia uma mensagem para o agente de mapeamento, que coleta informa\u00e7\u00f5es de mapeamento e, em seguida, informa todos os outros roteadores. Vamos descrever o processo de maneira an\u00e1loga ao Auto-RP:<br \/>\n1) Assim que configurarmos o R3 como candidato para ser RP, com o comando:<\/p>\n<blockquote><p>ip pim rp-candidate loopback 0<\/p><\/blockquote>\n<p>\nO R3 n\u00e3o far\u00e1 nada, para come\u00e7ar a enviar mensagens especiais, ele precisa primeiro encontrar o agente de mapeamento. Ent\u00e3o, passamos para o segundo passo.<br \/>\n2) Configuramos o R2 como agente de mapeamento:<\/p>\n<blockquote><p>ip pim bsr-candidate loopback 0<\/p><\/blockquote>\n<p>\nO R2 come\u00e7a a enviar mensagens PIM Bootstrap, se apresentando como agente de mapeamento:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/uAj49oT.jpg\"><img decoding=\"async\" alt=\"Princ\u00edpios de funcionamento do protocolo PIM\" src=\"\/wp-content\/uploads\/2019\/05\/2b05ffd64bd33ee5380aa24d5f76df67.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nEssa mensagem \u00e9 enviada para o endere\u00e7o 224.0.0.13, que o protocolo PIM usa tamb\u00e9m para outras de suas mensagens. Ele as envia em todas as dire\u00e7\u00f5es, portanto n\u00e3o h\u00e1 o problema da galinha e do ovo, como no Auto-RP.<br \/>\n3) Assim que o RP receber uma mensagem do roteador BSR, ele imediatamente enviar\u00e1 uma mensagem unicast para o endere\u00e7o do roteador BSR:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/qwtXY88.jpg\"><img decoding=\"async\" alt=\"Princ\u00edpios de funcionamento do protocolo PIM\" src=\"\/wp-content\/uploads\/2019\/05\/38547a114a2bca74131c95b95e535fdc.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nEm seguida, o BSR, ao receber as informa\u00e7\u00f5es sobre o RP, as disseminar\u00e1 via multicast para o endere\u00e7o 224.0.0.13, que \u00e9 monitorado por todos os roteadores PIM. Portanto, n\u00e3o existe um comando equivalente <i>ip pim autorp listener<\/i> para roteadores comuns no BSR.<br \/>\n<b>Anycast RP com o Protocolo de Descoberta de Fonte Multicast (MSDP).<\/b><br \/>\nAuto-RP e BSR nos permitem distribuir a carga no RP da seguinte forma: cada grupo multicast tem apenas um RP ativo. N\u00e3o \u00e9 poss\u00edvel distribuir a carga para um \u00fanico grupo multicast com v\u00e1rios RPs. O MSDP faz isso fornecendo aos roteadores RP o mesmo endere\u00e7o IP com uma m\u00e1scara de 255.255.255.255. O MSDP obt\u00e9m informa\u00e7\u00f5es atrav\u00e9s de um dos m\u00e9todos: est\u00e1tico, Auto-RP ou BSR.<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/U4aDz5H.png\"><img decoding=\"async\" alt=\"Princ\u00edpios de funcionamento do protocolo PIM\" src=\"\/wp-content\/uploads\/2019\/05\/c0352b5fbc5780f667c6c97ea6dde26d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nNa imagem temos a configura\u00e7\u00e3o do Auto-RP com MSDP. Ambos os RPs est\u00e3o configurados com o endere\u00e7o IP 172.16.1.1\/32 na interface Loopback 1 e \u00e9 usado para todos os grupos. Durante o RP-Announce, ambos os roteadores informam sobre si mesmos, referindo-se a esse endere\u00e7o. O agente de mapeamento Auto-RP, ao receber as informa\u00e7\u00f5es, dissemina a descoberta do RP com o endere\u00e7o 172.16.1.1\/32. Sobre a rede 172.16.1.1\/32, informamos aos roteadores por meio do IGP e, consequentemente. Assim, os roteadores PIM solicitam ou registram fluxos com o RP que est\u00e1 indicado como pr\u00f3ximo salto na rota para a rede 172.16.1.1\/32. O pr\u00f3prio protocolo MSDP \u00e9 destinado especificamente para os RPs, para trocar mensagens sobre informa\u00e7\u00f5es de multicast.<br \/>\nVamos considerar a seguinte topologia:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/zgkGDOP.jpg\"><img decoding=\"async\" alt=\"Princ\u00edpios de funcionamento do protocolo PIM\" src=\"\/wp-content\/uploads\/2019\/05\/e4823362e7a2abc9b4ee9ba954d709b8.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nO Switch6 transmite tr\u00e1fego para o endere\u00e7o 238.38.38.38, do qual apenas o RP-R1 est\u00e1 ciente. O Switch7 e o Switch8 solicitaram este grupo. Os roteadores R5 e R4 enviar\u00e3o PIM Join para R1 e R3, respectivamente. Por qu\u00ea? A rota at\u00e9 13.13.13.13 no R5 ir\u00e1 referir-se ao R1 pela m\u00e9trica do IGP, assim como no R4.<br \/>\nO RP-R1 est\u00e1 ciente do fluxo e come\u00e7ar\u00e1 a transmiti-lo em dire\u00e7\u00e3o ao R5, enquanto o R4 n\u00e3o possui conhecimento sobre ele, pois o R1 n\u00e3o o enviar\u00e1 apenas assim. Portanto, o MSDP se faz necess\u00e1rio. Vamos configur\u00e1-lo no R1 e R5:<\/p>\n<blockquote><p>ip msdp peer 3.3.3.3 connect-source Loopback1 no R1<\/p><\/blockquote>\n<p><\/p>\n<blockquote><p>ip msdp peer 1.1.1.1 connect-source Loopback3 no R3<\/p><\/blockquote>\n<p>\nEles estabelecer\u00e3o uma sess\u00e3o entre si e, ao receber qualquer fluxo, informar\u00e3o ao seu RP vizinho.<br \/>\nO RP-R1, assim que receber o fluxo do Switch6, enviar\u00e1 imediatamente uma mensagem MSDP Source-Active via unicasts, contendo informa\u00e7\u00f5es do tipo (S, G) \u2014 informa\u00e7\u00f5es sobre a origem e o destino do multicast. Agora, quando o RP-R3 souber que h\u00e1 uma origem como o Switch6, ao receber uma solicita\u00e7\u00e3o do R4 para esse fluxo, enviar\u00e1 um PIM Join em dire\u00e7\u00e3o ao Switch6, com base na tabela de roteamento. Portanto, o R1, ao receber tal PIM Join, come\u00e7ar\u00e1 a enviar tr\u00e1fego em dire\u00e7\u00e3o ao RP-R3.<br \/>\nO MSDP opera sobre TCP, e os RPs trocam mensagens de keepalive para verificar a viabilidade. O timer \u00e9 de 60 segundos.<br \/>\nA fun\u00e7\u00e3o de segmenta\u00e7\u00e3o dos pares do MSDP em diferentes dom\u00ednios permanece obscura, pois as mensagens Keepalive e SA n\u00e3o indicam a que dom\u00ednio pertencem. Al\u00e9m disso, nesta topologia, foi testada uma configura\u00e7\u00e3o com a indica\u00e7\u00e3o de diferentes dom\u00ednios \u2014 n\u00e3o houve diferen\u00e7a no funcionamento. <br \/>\nSe algu\u00e9m puder esclarecer, ficarei feliz em ler nos coment\u00e1rios.<br \/>\n<br \/>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/450582\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u043e\u0442\u043e\u043a\u043e\u043b PIM \u2014 \u044d\u0442\u043e \u043d\u0430\u0431\u043e\u0440 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u0434\u043b\u044f \u043f\u0435\u0440\u0435\u0434\u0430\u0447\u0438 \u043c\u0443\u043b\u044c\u0442\u0438\u043a\u0430\u0441\u0442\u0430 \u0432 \u0441\u0435\u0442\u0438 \u043c\u0435\u0436\u0434\u0443 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0442\u043e\u0440\u0430\u043c\u0438. \u041e\u0442\u043d\u043e\u0448\u0435\u043d\u0438\u044f \u0441\u043e\u0441\u0435\u0434\u0441\u0442\u0432\u0430 \u0441\u0442\u0440\u043e\u0438\u0442\u0441\u044f \u0430\u043d\u0430\u043b\u043e\u0433\u0438\u0447\u043d\u043e \u043a\u0430\u043a \u0438 \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u0434\u0438\u043d\u0430\u043c\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0446\u0438\u0438. PIMv2 \u043e\u0442\u043f\u0440\u0430\u0432\u043b\u044f\u0435\u0442 \u043a\u0430\u0436\u0434\u044b\u0435 30 \u0441\u0435\u043a\u0443\u043d\u0434 Hello \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u044f \u043d\u0430 \u0437\u0430\u0440\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0439 \u043c\u0443\u043b\u044c\u0442\u0438\u043a\u0430\u0441\u0442 \u0430\u0434\u0440\u0435\u0441 224.0.0.13 ( All-PIM-Routers ). \u0421\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0435 \u0441\u043e\u0434\u0435\u0440\u0436\u0438\u0442 \u0432 \u0441\u0435\u0431\u0435 Hold Timers \u2014 \u043e\u0431\u044b\u0447\u043d\u043e \u0440\u0430\u0432\u0435\u043d 3.5*Hello Timer, \u0442\u043e \u0435\u0441\u0442\u044c 105 \u0441\u0435\u043a\u0443\u043d\u0434 \u043f\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":24886,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-33142","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u043e\u0442\u043e\u043a\u043e\u043b PIM \u2014 \u044d\u0442\u043e \u043d\u0430\u0431\u043e\u0440 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u0434\u043b\u044f \u043f\u0435\u0440\u0435\u0434\u0430\u0447\u0438 \u043c\u0443\u043b\u044c\u0442\u0438\u043a\u0430\u0441\u0442\u0430 \u0432 \u0441\u0435\u0442\u0438 \u043c\u0435\u0436\u0434\u0443 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0442\u043e\u0440\u0430\u043c\u0438. \u041e\u0442\u043d\u043e\u0448\u0435\u043d\u0438\u044f \u0441\u043e\u0441\u0435\u0434\u0441\u0442\u0432\u0430 \u0441\u0442\u0440\u043e\u0438\u0442\u0441\u044f \u0430\u043d\u0430\u043b\u043e\u0433\u0438\u0447\u043d\u043e \u043a\u0430\u043a \u0438 \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u0434\u0438\u043d\u0430\u043c\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0446\u0438\u0438.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/printsipy-raboty-protokola-pim\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"pt_PT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041f\u0440\u0438\u043d\u0446\u0438\u043f\u044b \u0440\u0430\u0431\u043e\u0442\u044b \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0430 PIM | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u043e\u0442\u043e\u043a\u043e\u043b PIM \u2014 \u044d\u0442\u043e \u043d\u0430\u0431\u043e\u0440 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u0434\u043b\u044f \u043f\u0435\u0440\u0435\u0434\u0430\u0447\u0438 \u043c\u0443\u043b\u044c\u0442\u0438\u043a\u0430\u0441\u0442\u0430 \u0432 \u0441\u0435\u0442\u0438 \u043c\u0435\u0436\u0434\u0443 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0442\u043e\u0440\u0430\u043c\u0438. \u041e\u0442\u043d\u043e\u0448\u0435\u043d\u0438\u044f \u0441\u043e\u0441\u0435\u0434\u0441\u0442\u0432\u0430 \u0441\u0442\u0440\u043e\u0438\u0442\u0441\u044f \u0430\u043d\u0430\u043b\u043e\u0433\u0438\u0447\u043d\u043e \u043a\u0430\u043a \u0438 \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u0434\u0438\u043d\u0430\u043c\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0446\u0438\u0438.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/printsipy-raboty-protokola-pim\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:50:58+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:50:58+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Princ\u00edpios de funcionamento do protocolo PIM | ProHoster","description":"O protocolo PIM \u00e9 um conjunto de protocolos para transmiss\u00e3o de multicast em redes entre roteadores. As rela\u00e7\u00f5es de vizinhan\u00e7a s\u00e3o estabelecidas de maneira semelhante aos protocolos de roteamento din\u00e2mico.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/printsipy-raboty-protokola-pim","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041f\u0440\u0438\u043d\u0446\u0438\u043f\u044b \u0440\u0430\u0431\u043e\u0442\u044b \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0430 PIM | ProHoster","og:description":"\u041f\u0440\u043e\u0442\u043e\u043a\u043e\u043b PIM \u2014 \u044d\u0442\u043e \u043d\u0430\u0431\u043e\u0440 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u0434\u043b\u044f \u043f\u0435\u0440\u0435\u0434\u0430\u0447\u0438 \u043c\u0443\u043b\u044c\u0442\u0438\u043a\u0430\u0441\u0442\u0430 \u0432 \u0441\u0435\u0442\u0438 \u043c\u0435\u0436\u0434\u0443 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0442\u043e\u0440\u0430\u043c\u0438. \u041e\u0442\u043d\u043e\u0448\u0435\u043d\u0438\u044f \u0441\u043e\u0441\u0435\u0434\u0441\u0442\u0432\u0430 \u0441\u0442\u0440\u043e\u0438\u0442\u0441\u044f \u0430\u043d\u0430\u043b\u043e\u0433\u0438\u0447\u043d\u043e \u043a\u0430\u043a \u0438 \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u0434\u0438\u043d\u0430\u043c\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0446\u0438\u0438.","og:url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/printsipy-raboty-protokola-pim","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:50:58+00:00","article:modified_time":"2019-10-31T18:50:58+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"33142","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 14:06:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:46:23","updated":"2026-01-21 14:06:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/33142","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=33142"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/33142\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/24886"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=33142"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=33142"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=33142"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}