Exemplos: Configuração do gerenciamento de largura de banda
Entendendo o gerenciamento de largura de banda para Multicast
O gerenciamento de largura de banda permite que você controle os fluxos multicast que deixam uma interface multicast. Esse controle permite que você gerencie melhor seu tráfego multicast e reduza ou elimine as chances de sobreescrição ou congestionamento de interface.
O gerenciamento de largura de banda garante que a sobrescrição excessiva de tráfego multicast não ocorra em uma interface. Ao gerenciar a largura de banda multicast, você define a quantidade máxima de largura de banda multicast que uma interface individual pode usar, bem como os fluxos multicast individuais de largura de banda usados.
Por exemplo, o software de roteamento não pode adicionar um fluxo a uma interface se isso excede a largura de banda permitida para essa interface. Nestas circunstâncias, a interface é recusada. Essa rejeição, no entanto, não impede que um protocolo multicast (por exemplo, PIM) envie uma mensagem de junção upstream. O tráfego continua a chegar no roteador, embora o roteador não esteja enviando o fluxo das interfaces de saída esperadas.
Você pode configurar a largura de banda de fluxo estaticamente especificando um valor de largura de banda para o fluxo em bits por segundo, ou você pode permitir que a largura de banda de fluxo seja medida e alterada adaptativamente. Ao usar a opção de largura de banda adaptativa, o software de roteamento consulta as estatísticas para que os fluxos sejam medidos em intervalos de 5 segundos e calcula a largura de banda com base nas consultas. O software de roteamento usa o valor máximo medido no último minuto (ou seja, os últimos 12 pontos de medição) como largura de banda de fluxo.
Para obter mais informações, veja as seguintes seções:
Gerenciamento de largura de banda e reinício gracioso do PIM
Ao usar a reinicialização graciosa do PIM, após o processo de roteamento ser reiniciado no Mecanismo de Roteamento, interfaces previamente admitidas são sempre readmitidas e a largura de banda disponível é ajustada nas interfaces. Ao usar a opção de largura de banda adaptativa, a medição de largura de banda é inicialmente baseada na largura de banda inicial configurada ou padrão, o que pode ser impreciso durante o primeiro minuto. Isso significa que novos fluxos podem ser incorretamente rejeitados ou admitidos temporariamente. Você pode corrigir esse problema emitindo o comando operacional claro de admissão de largura de banda multicast .
Se a reinicialização graciosa do PIM não estiver configurada, após a reiniciação do processo de roteamento, interfaces previamente admitidas ou recusadas podem ser descartadas ou admitidas de maneira imprevisível.
Veja também
Gerenciamento de largura de banda e redundância de fonte
Ao usar redundância de origem, várias fontes (por exemplo, s1 e s2) podem existir para o mesmo grupo de destino (g). No entanto, apenas uma das fontes pode transmitir ativamente a qualquer momento. Neste caso, várias entradas de encaminhamento —(s1,g) e (s2,g) — são criadas após cada uma passar pelo processo de admissão.
Com fontes redundantes, ao contrário de entradas não relacionadas, uma OIF que já é admitida para uma entrada — por exemplo, (s1,g) — é automaticamente admitida para outras entradas de redundância — por exemplo, (s2,g). A largura de banda restante na interface é deduzida cada vez que uma interface de saída é adicionada, embora apenas um remetente transmita ativamente. Medindo a largura de banda, a largura de banda deduzida para as entradas inativas é creditada quando o roteador detecta que nenhum tráfego está sendo transmitido.
Para obter mais informações sobre a definição de fontes redundantes, veja Exemplo: Configuração de um mapa de fluxo multicast.
Sistemas lógicos e sobrescrição de largura de banda
Você pode gerenciar a largura de banda tanto no nível físico quanto lógico da interface . No entanto, se mais de um sistema lógico compartilhar a mesma interface física, a interface pode se tornar subscrita em excesso. A sobrescrição ocorre se a largura de banda total de todos os valores máximos de largura de banda configurados separadamente para as interfaces em cada sistema lógico exceder a largura de banda da interface física.
Ao exibir informações de largura de banda da interface, um valor de largura de banda disponível negativo indica sobrescrição na interface.
A largura de banda da interface pode ser subscrita demais quando a largura de banda máxima configurada diminui ou quando algumas larguras de banda de fluxo aumentam por causa de uma mudança de configuração ou um aumento real na taxa de tráfego.
A largura de banda da interface pode ficar disponível novamente se um dos seguintes ocorrer:
A largura de banda máxima configurada aumenta.
Alguns fluxos não são mais transmitidos de interfaces, e as reservas de largura de banda para eles agora estão disponíveis para outros fluxos.
Algumas larguras de banda de fluxo diminuem por causa de uma mudança de configuração ou uma redução real na taxa de tráfego.
Interfaces que são descartadas para um fluxo devido à largura de banda insuficiente não são readmitidas automaticamente, mesmo quando a largura de banda fica novamente disponível. As interfaces recusadas têm a oportunidade de serem readmitidas quando uma das seguintes ocorre:
O protocolo de roteamento multicast atualiza a entrada de encaminhamento para o fluxo após receber uma mensagem de entrada, licença ou podar ou após a ocorrência de uma mudança de topologia.
O protocolo de roteamento multicast atualiza a entrada de encaminhamento para o fluxo devido a mudanças na configuração.
Você reaplica manualmente o gerenciamento de largura de banda a um fluxo específico ou a todos os fluxos usando o comando operacional claro de admissão de largura de banda multicast .
Além disso, mesmo que a largura de banda anteriormente disponível não esteja mais disponível, interfaces já admitidas não são removidas até que uma das seguintes ocorra:
O protocolo de roteamento multicast remove explicitamente as interfaces após receber uma mensagem de licença ou podar ou após uma mudança de topologia.
Você reaplica manualmente o gerenciamento de largura de banda a um fluxo específico ou a todos os fluxos usando o comando operacional claro de admissão de largura de banda multicast .
Veja também
Exemplo: definir os máximos de largura de banda da interface
Este exemplo mostra como configurar a largura de banda máxima para uma interface física ou lógica.
Requisitos
Antes de começar:
Configure as interfaces do roteador.
Configure um protocolo de gateway interior. Consulte a biblioteca de protocolos de roteamento do Junos OS para dispositivos de roteamento.
Configure um protocolo multicast. Esse recurso funciona com os seguintes protocolos multicast:
DVMRP
PIM-DM
PIM-SM
PIM-SSM
Visão geral
A configuração máxima de largura de banda aplica o controle de admissão contra a largura de banda da interface configurada ou contra a velocidade nativa da interface subjacente (quando não há largura de banda configurada para a interface).
Se você configurar várias interfaces lógicas (por exemplo, para oferecer suporte a VLANs ou PVCs) na mesma interface física subjacente, e nenhuma largura de banda for configurada para as interfaces lógicas, assume-se que as interfaces lógicas todas têm a mesma largura de banda que a interface subjacente. Isso pode causar sobrescrição. Para evitar a sobrescrição, configure a largura de banda para as interfaces lógicas ou configure o controle de admissão no nível da interface física.
Você só precisa definir a largura de banda máxima para uma interface na qual você deseja aplicar o gerenciamento de largura de banda. Uma interface que não tem uma largura de banda máxima definida transmite todos os fluxos multicast conforme determinado pelo protocolo multicast que está sendo executado na interface (por exemplo, PIM).
Se você especificar a largura de banda máxima sem incluir um valor de bits por segundo, o controle de admissão é habilitado com base na largura de banda configurada para a interface. No exemplo a seguir, o controle de admissão é habilitado para a unidade de interface lógica 200, e a largura de banda máxima é de 20 Mbps. Se a largura de banda não estiver configurada na interface, a largura de banda máxima será a velocidade do enlace.
routing-options {
multicast {
interface fe-0/2/0.200 {
maximum-bandwidth;
}
interfaces {
fe-0/2/0 {
unit 200 {
bandwidth 20m;
}
}
}
Topologia
Configuração
Procedimento
Configuração rápida da CLI
Para configurar rapidamente este exemplo, copie os seguintes comandos, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere todos os detalhes necessários para combinar com a configuração da sua rede, copiar e colar os comandos na CLI no nível de [edit] hierarquia e, em seguida, entrar no commit modo de configuração.
set interfaces fe-0/2/0 unit 200 bandwidth 20m set routing-options multicast interface fe-0/2/0.200 maximum-bandwidth set routing-options multicast interface fe-0/2/1 maximum-bandwidth 60m set routing-options multicast interface fe-0/2/1.200 maximum-bandwidth 10m
Procedimento passo a passo
O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Usando o Editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.
Para configurar uma largura de banda no máximo:
Configure a largura de banda de uma interface lógica.
[edit interfaces] user@host# set fe-0/2/0 unit 200 bandwidth 20m
Habilite o controle de admissão na interface lógica.
[edit routing-options] user@host# set multicast interface fe-0/2/0.200 maximum-bandwidth
Em uma interface física, habilite o controle de admissão e defina a largura de banda máxima para 60 Mbps.
[edit routing-options] user@host# set multicast interface fe-0/2/1 maximum-bandwidth 60m
Para uma interface lógica na mesma interface física mostrada na Etapa 3, definir uma largura de banda máxima menor.
[edit routing-options] user@host# set multicast interface fe-0/2/1.200 maximum-bandwidth 10m
Resultados
Confirme sua configuração entrando nas interfaces de show e mostre comandos de opções de roteamento .
user@host# show interfaces
fe-0/2/0 {
unit 200 {
bandwidth 20m;
}
}
user@host# show routing-options
multicast {
interface fe-0/2/0.200 {
maximum-bandwidth;
}
interface fe-0/2/1 {
maximum-bandwidth 60m;
}
interface fe-0/2/1.200 {
maximum-bandwidth 10m;
}
}
Verificação
Para verificar a configuração, execute o comando de interface multicast show .
Exemplo: Configuração de multicast com VLANs de assinantes
Este exemplo mostra como configurar um roteador da Série MX para funcionar como um roteador de serviços de banda larga (BSR).
Requisitos
Este exemplo usa os seguintes componentes de hardware:
Um roteador da Série MX ou switch da Série EX com um PIC que oferece suporte a filas de perfil de controle de tráfego
Um DSLAM
Antes de começar:
Configure um protocolo de gateway interior. Consulte a biblioteca de protocolos de roteamento do Junos OS para dispositivos de roteamento.
Configure PIM, IGMP ou MLD nas interfaces.
Visão geral e topologia
Quando várias interfaces BSR recebem IGMP e MLD se juntam e deixam solicitações para o mesmo fluxo multicast, o BSR envia uma cópia do fluxo multicast em cada interface. Tanto os pacotes de controle multicast (IGMP e MLD) quanto os pacotes de dados multicast fluem na mesma interface BSR, juntamente com os dados unicast. Como todo tráfego por cliente tem sua própria interface no BSR, contabilidade por cliente, controle de admissão de chamadas (CAC) e ajuste de qualidade de serviço (QoS). A largura de banda QoS usada por multicast reduz a largura de banda unicast.
Várias interfaces no BSR podem se conectar a um dispositivo compartilhado (por exemplo, um DSLAM). O BSR envia o mesmo fluxo multicast várias vezes para o dispositivo compartilhado, desperdiçando assim a largura de banda. É mais eficiente enviar o fluxo multicast uma vez para o DSLAM e replicar os fluxos multicast no DSLAM. Existem duas abordagens que você pode usar.
A primeira abordagem é continuar a enviar dados unicast nas interfaces por cliente, mas ter a rota DSLAM todos os IGMP e MLD por cliente juntam-se e deixam solicitações ao BSR em uma única interface dedicada (uma VLAN multicast). O DSLAM recebe os fluxos multicast do BSR na interface dedicada sem replicação desnecessária e realiza a replicação necessária aos clientes. Como todos os pacotes de dados e controle multicast usam apenas uma interface, apenas uma cópia de um fluxo é enviada mesmo se houver várias solicitações. Essa abordagem é chamada de mapeamento de interface de saída reversa (OIF). O mapeamento OIF reverso permite que o BSR propagasse o estado multicast da interface compartilhada para as interfaces do cliente, o que permite que a contabilidade por cliente e o ajuste de QoS funcionem. Quando um cliente muda o canal de TV, o gateway de roteador (RG) envia um IGMP ou MLD, juntando-se e deixando mensagens para o DSLAM. O DSLAM passa a solicitação de forma transparente ao BSR por meio da VLAN multicast. O BSR mapeia a solicitação de IGMP ou MLD a uma das VLANs assinantes com base no endereço de origem IP ou no endereço MAC de origem. Quando o VLAN assinante é encontrado, o ajuste de QoS e a contabilidade são perfomed nessa VLAN ou interface.
A segunda abordagem é que o DSLAM continue a enviar dados unicast e todos os IGMP e MLD por cliente participem e deixem solicitações ao BSR nas interfaces individuais do cliente, mas para que os fluxos multicast cheguem em uma única interface dedicada. Se vários clientes solicitarem o mesmo fluxo multicast, o BSR enviará uma cópia dos dados na interface dedicada. O DSLAM recebe os fluxos multicast do BSR na interface dedicada e realiza a replicação necessária para os clientes. Como os pacotes de controle multicast usam muitas interfaces de clientes, a configuração no BSR deve especificar como mapear os pacotes de dados multicast de cada cliente para a interface de saída dedicada única. O ajuste de QoS é suportado nas interfaces do cliente. O CAC é compatível com a interface compartilhada. Essa segunda abordagem é chamada de mapeamento OIF multicast.
Mapeamento OIF e mapeamento OIF reverso não são suportados na mesma interface do cliente ou interface compartilhada. Este exemplo mostra como configurar as duas abordagens diferentes. Ambas as abordagens oferecem suporte a ajustes de QoS e ambas as abordagens oferecem suporte ao MLD/IPv6. O exemplo de mapeamento OIF reverso se concentra no IGMP/IPv4 e permite ajustes de QoS. O exemplo de mapeamento OIF se concentra no MLD/IPv6 e desativa o ajuste de QoS.
A primeira abordagem (mapeamento OIF reverso) inclui as seguintes declarações:
mapa de fluxo — define um mapa de fluxo que controla a largura de banda para cada fluxo.
largura de banda máxima — habilita o CAC.
mapeamento reverso de oif — permite que o dispositivo de roteamento identifique um VLAN ou interface de assinante com base em um IGMP ou MLD participe ou deixe a solicitação que ele recebe pelo VLAN multicast.
Após a identificação do VLAN assinante, o dispositivo de roteamento ajusta imediatamente o QoS (neste caso, a largura de banda) nesse VLAN com base na adição ou remoção de um assinante.
O dispositivo de roteamento usa IGMP e MLD para juntar ou deixar relatórios para obter as informações de VLAN do assinante. Isso significa que o equipamento de conexão (por exemplo, o DSLAM) deve encaminhar todos os relatórios IGMP e MLD para o dispositivo de roteamento para que esse recurso funcione corretamente. Usar a supressão de relatórios ou um proxy IGMP pode resultar em mapeamento OIF reverso sem funcionar corretamente.
temporizantes para assinantes — apresenta um atraso na atualização do QoS. Após receber uma solicitação de licença IGMP ou MLD, esta declaração define um atraso de tempo (entre 1 e 30 segundos) que o dispositivo de roteamento espera antes de atualizar o QoS para as interfaces de assinante restantes. Você pode usar esse atraso para diminuir a frequência com que o dispositivo de roteamento ajusta a largura de banda QoS geral na VLAN quando um assinante envia licença rápida e junta mensagens (por exemplo, ao mudar de canal em uma rede IPTV).
perfil de controle de tráfego — configura uma taxa de modelagem na interface lógica. A taxa de configuração configurada deve ser configurada como um valor absoluto, não como uma porcentagem.
A segunda abordagem (mapeamento OIF) inclui as seguintes declarações:
mapa a interface — em uma declaração de política, permite que você construa o mapa OIF.
O mapa OIF é uma declaração de política de roteamento que pode conter vários termos. Ao criar mapas OIF, lembre-se do seguinte:
Se você especificar uma interface física (por exemplo, ge-0/0/0), uma ".0" é anexada à interface para criar uma interface lógica (por exemplo, ge-0/0/0,0).
Configure uma política de roteamento para cada sistema lógico. Você não pode configurar políticas de roteamento dinamicamente.
A interface também deve ter IGMP, MLD ou PIM configurados.
Você não pode mapear para uma interface mapeada.
Recomendamos que você configure declarações de políticas para IGMP e MLD separadamente.
Especifique uma interface lógica ou a palavra-chave self. A auto-palavra-chave especifica que pacotes de dados multicast sejam enviados na mesma interface que os pacotes de controle e que nenhum mapeamento ocorre. Se nenhum termo for correspondido, nenhum pacote de dados multicast será enviado.
não ajuste qos — desativa o ajuste de QoS.
O ajuste de QoS diminui a largura de banda disponível na interface do cliente pela quantidade de largura de banda consumida pelos fluxos multicast que são mapeados da interface do cliente para a interface compartilhada. Essa ação sempre ocorre a menos que seja explicitamente desativada.
Se você desativar o ajuste de QoS, a largura de banda disponível não será reduzida na interface do cliente quando fluxos multicast são adicionados à interface compartilhada.
Nota:Você pode desativar dinamicamente o ajuste de QoS para interfaces IGMP e MLD usando perfis dinâmicos.
oif-map — Associe um mapa com uma interface IGMP ou MLD. O mapa OIF é então aplicado a todas as solicitações de IGMP ou MLD recebidas na interface configurada. Neste exemplo, as VLANs assinantes 1 e 2 têm MLD configurado, e cada VLAN aponta para um mapa OIF que direciona algum tráfego para ge-2/3/9.4000, algum tráfego para ge-2/3/9.4001, e algum tráfego para si mesmo.
Nota:Você pode associar dinamicamente mapas OIF com interfaces IGMP usando perfis dinâmicos.
passiva — define IGMP ou MLD para usar o modo passivo.
A interface de mapa OIF normalmente não deve passar pelo tráfego de controle IGMP ou MLD e deve ser configurada como passiva. No entanto, a implementação do mapa OIF oferece suporte à execução de IGMP ou MLD em uma interface (controle e dados), além de mapear fluxos de dados para a mesma interface. Neste caso, você deve configurar IGMP ou MLD normalmente (ou seja, não no modo passivo) na interface mapeada. Neste exemplo, as interfaces de mapa OIF (ge-2/3/9.4000 e ge-2/3/9.4001) são configuradas como passivas de MLD.
Por padrão, especificar a declaração passiva significa que nenhuma consulta geral, consultas específicas de grupo ou consultas específicas de fonte de grupo são enviadas pela interface e que todo o tráfego de controle recebido é ignorado pela interface. No entanto, você pode ativar seletivamente até duas das três opções disponíveis para a declaração passiva , mantendo as outras funções passivas (inativas).
Essas opções incluem:
consulta geral de envio — quando especificada, a interface envia consultas gerais.
consulta de grupo de envio — Quando especificada, a interface envia consultas específicas do grupo e específicas de fonte de grupo.
permitir o recebimento — quando especificada, a interface recebe tráfego de controle.
Topologia
A Figura 1 mostra o cenário.
Em ambas as abordagens, se vários clientes solicitarem o mesmo fluxo multicast, o BSR envia uma cópia do fluxo na interface VLAN multicast compartilhada. O DSLAM recebe o fluxo multicast do BSR na interface compartilhada e realiza a replicação necessária para os clientes.
Na primeira abordagem (mapeamento OIF reverso), o DSLAM usa as VLANs por assinante por cliente apenas para dados unicast. As solicitações de adesão e licença de IGMP e MLD são enviadas na VLAN multicast.
Na segunda abordagem (mapeamento OIF), o DSLAM usa as VLANs por assinantes para dados unicast e para solicitações de adesão e licença de IGMP e MLD. O VLAN multicast é usado apenas para fluxos multicast, não para solicitações de entrada e saída.
Configuração
Configuração de um mapa OIF reverso
Configuração rápida da CLI
Para configurar este exemplo rapidamente, copie os seguintes comandos, cole-os em um arquivo de texto, remova qualquer quebra de linha, altere todos os detalhes necessários para combinar com a configuração da sua rede, copiar e colar os comandos na CLI no nível de [edit] hierarquia e, em seguida, entrar no commit modo de configuração.
set class-of-service traffic-control-profiles tcp-ifl shaping-rate 20m set class-of-service interfaces ge-2/2/0 shaping-rate 240m set class-of-service interfaces ge-2/2/0 unit 50 output-traffic-control-profile tcp-ifl set class-of-service interfaces ge-2/2/0 unit 51 output-traffic-control-profile tcp-ifl set interfaces ge-2/0/0 unit 0 family inet address 30.0.0.2/24 set interfaces ge-2/2/0 hierarchical-scheduler set interfaces ge-2/2/0 vlan-tagging set interfaces ge-2/2/0 unit 10 vlan-id 10 set interfaces ge-2/2/0 unit 10 family inet address 40.0.0.2/24 set interfaces ge-2/2/0 unit 50 vlan-id 50 set interfaces ge-2/2/0 unit 50 family inet address 50.0.0.2/24 set interfaces ge-2/2/0 unit 51 vlan-id 51 set interfaces ge-2/2/0 unit 51 family inet address 50.0.1.2/24 set policy-options policy-statement all-mcast-groups from source-address-filter 30.0.0.0/8 orlonger set policy-options policy-statement all-mcast-groups then accept set protocols igmp interface all set protocols igmp interface fxp0.0 disable set protocols pim rp local address 20.0.0.2 set protocols pim interface all set protocols pim interface fxp0.0 disable set protocols pim interface ge-2/2/0.10 disable set routing-options multicast flow-map map1 policy all-mcast-groups set routing-options multicast flow-map map1 bandwidth 10m set routing-options multicast flow-map map1 bandwidth adaptive set routing-options multicast interface ge-2/2/0.10 maximum-bandwidth 500m set routing-options multicast interface ge-2/2/0.10 reverse-oif-mapping set routing-options multicast interface ge-2/2/0.10 subscriber-leave-timer 20
Procedimento passo a passo
O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Usando o Editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.
Para configurar o mapeamento OIF reverso:
Configure uma interface lógica para tráfego de dados unicast.
[edit interfaces ge-2/0/0] user@host# set unit 0 family inet address 30.0.0.2/24
Configure uma interface lógica para o tráfego de controle de assinantes.
[edit interfaces ge-2/2/0] user@host# set hierarchical-scheduler user@host# set vlan-tagging user@host# set unit 10 vlan-id 10 user@host# set unit 10 family inet address 40.0.0.2/24
Configure duas interfaces lógicas nas quais os ajustes de QoS são feitos.
[edit interfaces ge-2/2/0] user@host# set unit 50 vlan-id 50 user@host# set unit 50 family inet address 50.0.0.2/24 user@host# set unit 51 vlan-id 51 user@host# set unit 51 family inet address 50.0.1.2/24
Configure uma política.
[edit policy-options policy-statement all-mcast-groups] user@host# set from source-address-filter 30.0.0.0/8 orlonger user@host# set then accept
Habilite um mapa de fluxo que faça referência à política.
[edit routing-options multicast] user@host# set flow-map map1 policy all-mcast-groups user@host# set flow-map map1 bandwidth 10m adaptive
Habilite o mapeamento OIF na interface lógica que recebe tráfego de controle de assinantes.
[edit routing-options multicast] user@host# set interface ge-2/2/0.10 maximum-bandwidth 500m user@host# set interface ge-2/2/0.10 reverse-oif-mapping user@host# set interface ge-2/2/0.10 subscriber-leave-timer 20
Configure o PIM e o IGMP.
[edit protocols] user@host# set igmp interface all user@host# set igmp interface fxp0.0 disable user@host# set pim rp local address 20.0.0.2 user@host# set pim interface all user@host# set pim interface fxp0.0 disable user@host# set pim interface ge-2/2/0.10 disable
Configure o agendador hierárquico configurando uma taxa de modelagem para a interface física e uma taxa de modelagem mais lenta para as interfaces lógicas nas quais os ajustes de QoS são feitos.
[edit class-of-service interfaces ge-2/2/0] user@host# set shaping-rate 240m user@host# set unit 50 output-traffic-control-profile tcp-ifl user@host# set unit 51 output-traffic-control-profile tcp-ifl [edit class-of-service traffic-control-profiles tcp-30m-no-smap] user@host# set shaping-rate 20m
Resultados
A partir do modo de configuração, confirme sua configuração entrando na classe de serviço show, mostrar interfaces, mostrar opções de políticas, mostrar protocolos e mostrar comandos de opções de roteamento . Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.
user@host# show class-of-service
traffic-control-profiles {
tcp-ifl {
shaping-rate 20m;
}
}
interfaces {
ge-2/2/0 {
shaping-rate 240m;
unit 50 {
output-traffic-control-profile tcp-ifl;
}
unit 51 {
output-traffic-control-profile tcp-ifl;
}
}
}
user@host# show interfaces
ge-2/0/0 {
unit 0 {
family inet {
address 30.0.0.2/24;
}
}
}
ge-2/2/0 {
hierarchical-scheduler;
vlan-tagging;
unit 10 {
vlan-id 10;
family inet {
address 40.0.0.2/24;
}
}
unit 50 {
vlan-id 50;
family inet {
address 50.0.0.2/24;
}
}
unit 51 {
vlan-id 51;
family inet {
address 50.0.1.2/24;
}
}
}
user@host# show policy-options
policy-statement all-mcast-groups {
from {
source-address-filter 30.0.0.0/8 orlonger;
}
then accept;
}
user@host# show protocols
igmp {
interface all;
interface fxp0.0 {
disable;
}
}
pim {
rp {
local {
address 20.0.0.2;
}
}
interface all;
interface fxp0.0 {
disable;
}
interface ge-2/2/0.10 {
disable;
}
}
user@host# show routing-options
multicast {
flow-map map1 {
policy all-mcast-groups;
bandwidth 10m adaptive;
}
interface ge-2/2/0.10 {
maximum-bandwidth 500m;
reverse-oif-mapping;
subscriber-leave-timer 20;
}
}
Se você terminar de configurar o dispositivo, insira o commit a partir do modo de configuração.
Configuração de um mapa OIF
Configuração rápida da CLI
Para configurar rapidamente este exemplo, copie os seguintes comandos, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere todos os detalhes necessários para combinar com a configuração da sua rede, copiar e colar os comandos na CLI no nível de [edit] hierarquia e, em seguida, entrar no commit modo de configuração.
set interfaces ge-2/3/8 unit 0 family inet6 address C300:0101::/24 set interfaces ge-2/3/9 vlan-tagging set interfaces ge-2/3/9 unit 1 vlan-id 1 set interfaces ge-2/3/9 unit 1 family inet6 address C400:0101::/24 set interfaces ge-2/3/9 unit 2 vlan-id 2 set interfaces ge-2/3/9 unit 2 family inet6 address C400:0201::/24 set interfaces ge-2/3/9 unit 4000 vlan-id 4000 set interfaces ge-2/3/9 unit 4000 family inet6 address C40F:A001::/24 set interfaces ge-2/3/9 unit 4001 vlan-id 4001 set interfaces ge-2/3/9 unit 4001 family inet6 address C40F:A101::/24 set policy-options policy-statement g539-v6 term g539-4000 from route-filter FF05:0101:0000::/39 orlonger set policy-options policy-statement g539-v6 term g539-4000 then map-to-interface ge-2/3/9.4000 set policy-options policy-statement g539-v6 term g539-4000 then accept set policy-options policy-statement g539-v6 term g539-4001 from route-filter FF05:0101:0200::/39 orlonger set policy-options policy-statement g539-v6 term g539-4001 then map-to-interface ge-2/3/9.4001 set policy-options policy-statement g539-v6 term g539-4001 then accept set policy-options policy-statement g539-v6 term self from route-filter FF05:0101:0700::/40 orlonger set policy-options policy-statement g539-v6 term self then map-to-interface self set policy-options policy-statement g539-v6 term self then accept set policy-options policy-statement g539-v6-all term g539 from route-filter 0::/0 orlonger set policy-options policy-statement g539-v6-all term g539 then map-to-interface ge-2/3/9.4000 set policy-options policy-statement g539-v6-all term g539 then accept set protocols mld interface fxp0.0 disable set protocols mld interface ge-2/3/9.4000 passive set protocols mld interface ge-2/3/9.4001 passive set protocols mld interface ge-2/3/9.1 version 1 set protocols mld interface ge-2/3/9.1 oif-map g539-v6 set protocols mld interface ge-2/3/9.2 version 2 set protocols mld interface ge-2/3/9.2 oif-map g539-v6 set protocols pim rp local address 20.0.0.4 set protocols pim rp local family inet6 address C000::1 set protocols pim interface ge-2/3/8.0 mode sparse set protocols pim interface ge-2/3/8.0 version 2 set routing-options multicast interface ge-2/3/9.1 no-qos-adjust set routing-options multicast interface ge-2/3/9.2 no-qos-adjust
Procedimento passo a passo
O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte o Guia de usuário do Junos OS CLI.
Para configurar o mapeamento OIF reverso:
Configure uma interface lógica para tráfego de dados unicast.
[edit interfaces ge-2/3/8 ] user@host# set unit 0 family inet6 address C300:0101::/24
Configure interfaces lógicas para VLANs assinantes.
[edit interfaces ge-2/3/9] user@host# set vlan-tagging user@host# set unit 1 vlan-id 1 user@host# set unit 1 family inet6 address C400:0101::/24 user@host# set unit 2 vlan-id 2 user@host# set unit 2 family inet6 address C400:0201::/24 lo0 unit 0 family inet6 address C000::1/128 user@host# set unit 2 family inet6 address C400:0201::/24
Configure duas interfaces lógicas de mapa a segundo.
[edit interfaces ge-2/2/0] user@host# set unit 4000 vlan-id 4000 user@host# set unit 4000 family inet6 address C40F:A001::/24 user@host# set unit 4001 vlan-id 4001 user@host# set unit 4001 family inet6 address C40F:A101::/24
Configure o mapa OIF.
[edit policy-options policy-statement g539-v6] user@host# set term g539-4000 from route-filter FF05:0101:0000::/39 orlonger user@host# set then map-to-interface ge-2/3/9.4000 user@host# set then accept user@host# set term g539-4001 from route-filter FF05:0101:0200::/39 orlonger user@host# set then map-to-interface ge-2/3/9.4001 user@host# set then accept user@host# set term self from route-filter FF05:0101:0700::/40 orlonger user@host# set then map-to-interface self user@host# set then accept [edit policy-options policy-statement g539-v6-all] user@host# set term g539 from route-filter 0::/0 orlonger user@host# set then map-to-interface ge-2/3/9.4000 user@host# set then accept
Desabitile o ajuste de QoS nas VLANs de assinantes.
[edit routing-options multicast] user@host# set interface ge-2/3/9.1 no-qos-adjust user@host# set interface ge-2/3/9.2 no-qos-adjust
Configure o PIM e o MLD. Aponte as VLANs de assinantes MLD para o mapa OIF.
[edit protocols] user@host# set pim rp local address 20.0.0.4 user@host# set pim rp local family inet6 address C000::1 #C000::1 is the address of lo0 user@host# set pim interface ge-2/3/8.0 mode sparse user@host# set pim interface ge-2/3/8.0 version 2 user@host# set mld interface fxp0.0 disable user@host# set interface ge-2/3/9.4000 passive user@host# set interface ge-2/3/9.4001 passive user@host# set interface ge-2/3/9.1 version 1 user@host# set interface ge-2/3/9.1 oif-map g539-v6 user@host# set interface ge-2/3/9.2 version 2 user@host# set interface ge-2/3/9.2 oif-map g539-v6
Resultados
A partir do modo de configuração, confirme sua configuração entrando nas interfaces de exibição, mostre opções de políticas, mostre protocolos e mostre comandos de opções de roteamento . Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.
user@host# show interfaces
ge-2/3/8 {
unit 0 {
family inet6 {
address C300:0101::/24;
}
}
}
ge-2/3/9 {
vlan-tagging;
unit 1 {
vlan-id 1;
family inet6 {
address C400:0101::/24;
}
}
unit 2 {
vlan-id 2;
family inet6 {
address C400:0201::/24;
}
}
unit 4000 {
vlan-id 4000;
family inet6 {
address C40F:A001::/24;
}
}
unit 4001 {
vlan-id 4001;
family inet6 {
address C40F:A101::/24;
}
}
}
user@host# show policy-options
policy-statement g539-v6 {
term g539-4000 {
from {
route-filter FF05:0101:0000::/39 orlonger;
}
then {
map-to-interface ge-2/3/9.4000;
accept;
}
}
term g539-4001 {
from {
route-filter FF05:0101:0200::/39 orlonger;
}
then {
map-to-interface ge-2/3/9.4001;
accept;
}
}
term self {
from {
route-filter FF05:0101:0700::/40 orlonger;
}
then {
map-to-interface self;
accept;
}
}
}
policy-statement g539-v6-all {
term g539 {
from {
route-filter 0::/0 orlonger;
}
then {
map-to-interface ge-2/3/9.4000;
accept;
}
}
}
user@host# show protocols
mld {
interface fxp0.0 {
disable;
}
interface ge-2/3/9.4000 {
passive;
}
interface ge-2/3/9.4001 {
passive;
}
interface ge-2/3/9.1 {
version 1;
oif-map g539-v6;
}
interface ge-2/3/9.2 {
version 2;
oif-map g539-v6;
}
}
pim {
rp {
local {
address 20.0.0.4;
family inet6 {
address C000::1;
}
}
}
interface ge-2/3/8.0 {
mode sparse;
version 2;
}
}
user@host# show routing-options
multicast {
interface ge-2/3/9.1 no-qos-adjust;
interface ge-2/3/9.2 no-qos-adjust;
}
Se você terminar de configurar o dispositivo, insira o commit a partir do modo de configuração.
Verificação
Para verificar a configuração, execute os seguintes comandos:
mostrar estatísticas do igmp
mostrar interface de classe de serviço
estatísticas de interfaces de exibição
mostrar estatísticas de mld
mostrar interface multicast
política de exibição
Configuração do roteamento multicast em interfaces de IP Demux
Em uma rede de gerenciamento de assinantes, os campos em pacotes enviados de interfaces de IP demux destinam-se a corresponder a um cliente específico que reside do outro lado de um dispositivo de agregação (por exemplo, um nó de acesso multisserviço [MSAN]). No entanto, os pacotes enviados de um roteador de serviços de banda larga (BSR) para um MSAN não identificam a interface de demux. Assim que ele obtém um pacote, cabe ao dispositivo MSAN determinar qual cliente recebe o pacote.
Dependendo da inteligência do dispositivo MSAN, determinar qual cliente recebe o pacote pode ocorrer de forma ineficiente. Por exemplo, quando ele recebe tráfego de controle IGMP, um MSAN pode encaminhar o tráfego de controle para todos os clientes, em vez do cliente pretendido. Além disso, uma vez estabelecido um destino de fluxo de dados, embora um MSAN possa usar a espionagem do IGMP para determinar quais hosts residem em um determinado grupo e limitar fluxos de dados a apenas esse grupo, o MSAN ainda deve enviar várias cópias do fluxo de dados para cada membro do grupo, mesmo que esse fluxo de dados seja destinado a apenas um cliente no grupo.
Vários recursos multicast, quando combinados, permitem que você evite as ineficiências mencionadas acima. Esses recursos incluem:
A capacidade de configurar a declaração da família de interface de IP demux para usar a inet para a interface primária numerada ou não numerada.
A capacidade de configurar o IGMP na interface principal para enviar consultas gerais para todos os clientes. A configuração de demux impede que a interface IGMP primária receba pacotes de controle IGMP do cliente. Em vez disso, todos os pacotes de controle de IGMP vão para as interfaces de demux. No entanto, para garantir que nenhuma participação ocorra na interface principal:
Para interfaces IGMP estáticas — inclua a declaração passiva de consulta geral de envio na configuração IGMP no nível hierárquico [editar protocolos igmp interface interface-name] .
Para interfaces dinâmicas de demux IGMP — inclua a declaração passiva de consulta geral de envio no nível de hierarquia [editar protocolos de perfis dinâmicos profile-name ] interface-name nível de hierarquia.
A capacidade de mapear todos os grupos multicast para a interface principal da seguinte forma:
Para interfaces IGMP estáticas — inclua a declaração de mapa oif no nível de hierarquia [editar protocolos igmp interface interface-name] .
Para interfaces de demux IGMP dinâmicas — inclua a declaração de mapa oif no nível de hierarquia [editar protocolos de perfis dinâmicos profile-name ] de interface interface-nameigmp .
Usando a declaração do oif-map , você pode mapear o mesmo grupo IGMP para a mesma interface de saída e enviar apenas uma cópia do fluxo multicast da interface.
A capacidade de configurar o IGMP em cada interface de demux. Para evitar consultas gerais duplicadas:
Para interfaces de IGMP estáticas — inclua a declaração passiva de solicitação de envio de grupo no nível hierárquico [editar protocolos igmp interface interface-name] .
Para interfaces dinâmicas de demux — inclua a declaração passiva de solicitação de envio de grupo no nível de hierarquia [editar protocolos de perfis dinâmicos profile-name igmp]interface-name.
Nota:Para enviar apenas uma cópia de cada grupo, independentemente de quantos clientes participem, use a declaração do mapa oif como mencionado anteriormente.
Veja também
Classificação de pacotes por interface de saída
Para roteadores de borda multisserviços M320 da Juniper Networks e roteadores de núcleo da Série T com as interfaces de enfileiramento inteligente (IQ), IQ2, IQ aprimorada (IQE), interfaces de serviços de enlace multisserviços com fila inteligente (LSQ) ou PICs ATM2, você pode classificar pacotes unicast e multicast com base na interface de saída. Para tráfego unicast, você também pode usar um filtro multicampo, mas apenas a classificação de interface de saída se aplica ao tráfego multicast, bem como ao tráfego unicast. Se você configurar a classificação de saída de uma interface, não poderá realizar reescritas de ponto de código de serviços diferenciados (DSCP) na interface. Por padrão, o sistema não executa nenhuma classificação com base na interface de saída.
Em um roteador da Série MX que contém MPCs e MS-DPCs, pacotes multicast são descartados no roteador e não são processados corretamente se o roteador contém interfaces lógicas MLPPP LSQ que funcionam como receptores multicast e se o modo de serviços de rede for configurado como modo IP aprimorado no roteador. Esse comportamento é esperado com interfaces LSQ em conjunto com o modo IP aprimorado. Nesse cenário, se o modo IP aprimorado não estiver configurado, a multicasting funciona corretamente. No entanto, se o roteador contém interfaces LSQ redundantes e o modo de serviços de rede IP aprimorado configurado com a localização da FIB, o multicast funciona corretamente.
Para habilitar a classificação de pacotes pela interface de saída, você configura primeiro um mapa de classe de encaminhamento e um ou mais números de fila para a interface de saída no nível de [edit class-of-service forwarding-class-map forwarding-class-map-name] hierarquia:
[edit class-of-service] forwarding-classes-interface-specific forwarding-class-map-name { class class-name queue-num queue-number [ restricted-queue queue-number ]; }
Para roteadores da Série T que estão restritos a apenas quatro filas, você pode controlar a atribuição de fila com a opção restricted-queue ou permitir que o sistema determine automaticamente a fila de forma modular. Por exemplo, um mapa que atribui pacotes à fila 6 mapearia para a fila 2 em um sistema de quatro filas.
Se você configurar um mapa de classe de encaminhamento de saída associando uma classe de encaminhamento a um número de fila, este mapa não será suportado em interfaces de enfileiramento inteligente (lsq-) de serviços de link de vários serviços.
Uma vez configurado o mapa de classe de encaminhamento, você aplica o mapa na interface lógica usando a output-forwarding-class-map declaração no nível de [edit class-of-service interfaces interface-name unit logical-unit-number ] hierarquia:
[edit class-of-service interfaces interface-name unit logical-unit-number] output-forwarding-class-map forwarding-class-map-name;
Todos os parâmetros relacionados às filas e à classe de encaminhamento também devem ser configurados. Para obter mais informações sobre a configuração de aulas de encaminhamento e filas, consulte Configurando uma classe de encaminhamento personalizada para cada fila.
Este exemplo mostra como configurar um mapa de classe de encaminhamento específico da interface chamado FCMAP1 que restringe as filas 5 e 6 a diferentes filas em sistemas de quatro filas FCMAP1 e depois se aplica à unit 0 interface ge-6/0/0:
[edit class-of-service]
forwarding-class-map FCMAP1 {
class FC1 queue-num 6 restricted-queue 3;
class FC2 queue-num 5 restricted-queue 2;
class FC3 queue-num 3;
class FC4 queue-num 0;
class FC3 queue-num 0;
class FC4 queue-num 1;
}
[edit class-of-service]
interfaces {
ge-6/0/0 unit 0 {
output-forwarding-class-map FCMAP1;
}
}
Observe que, sem a opção restricted-queue em FCMAP1, o exemplo atribuiria FC1 e FC2 às filas 2 e 1, respectivamente, em um sistema restrito a quatro filas.
Use o show class-of-service forwarding-class forwarding-class-map-name comando para exibir a configuração de fila de mapa da classe de encaminhamento:
user@host> show class-of-service forwarding-class FCMAP2 Forwarding class ID Queue Restricted queue FC1 0 6 3 FC2 1 5 2 FC3 2 3 3 FC4 3 0 0 FC5 4 0 0 FC6 5 1 1 FC7 6 6 2 FC8 7 7 3
Use o show class-of-service interface interface-name comando para exibir os mapas da classe de encaminhamento (e outras informações) atribuídos a uma interface lógica:
user@host> show class-of-service interface ge-6/0/0 Physical interface: ge-6/0/0, Index: 128 Queues supported: 8, Queues in use: 8 Scheduler map: <default>, Index: 2 Input scheduler map: <default>, Index: 3 Chassis scheduler map: <default-chassis>, Index: 4 Logical interface: ge-6/0/0.0, Index: 67 Object Name Type Index Scheduler-map sch-map1 Output 6998 Scheduler-map sch-map1 Input 6998 Classifier dot1p ieee8021p 4906 forwarding-class-map FCMAP1 Output 1221 Logical interface: ge-6/0/0.1, Index 68 Object Name Type Index Scheduler-map <default> Output 2 Scheduler-map <default> Input 3 Logical interface: ge-6/0/0.32767, Index 69 Object Name Type Index Scheduler-map <default> Output 2 Scheduler-map <default> Input 3
Reciclar o gerenciamento de largura de banda
Os roteadores ACX usam a interface de reciclagem para loopback ou recircular tráfego da interface de saída até a entrada para processamento adicional. Isso é necessário para aplicativos que exigem processamento adicional.
A interface de reciclagem é uma interface canalizada interna que tem um shaper de saída que limita a taxa de fluxo do tráfego de saída. Por padrão, a largura de banda da interface de reciclagem é baseada em sobrescrição de chassis e configuração específica de FPC ou interface da plataforma.
Aplicativos que usam o mecanismo de reciclagem, configuram canais ou portas virtuais com base na necessidade, que por sua vez passa por um shaper de aplicativo semelhante ao shaper de saída na interface de reciclagem. A interface de reciclagem pode suportar um máximo de 256 canais ou portas lógicas virtuais. Todos os canais de reciclagem operam com a mesma prioridade. O tráfego reciclado é então encaminhado usando o slot de calendário com base no peso atribuído a ele. Outros tipos de interfaces como a interface NIF encaminham o tráfego ocupando outros slots no calendário proporcionais à sua largura de banda.
A Figura 1 ilustra o mecanismo de reciclagem e seus componentes.
de reciclagem
-
Sh1 – Formato de interface de reciclamento
-
SA1 – Shaper de aplicativo 1 sobre o canal de reciclagem 1
-
SAn — Shaper de #n de aplicativo sobre canal de reciclagem n (máximo 256)
-
B1 – Peso de slot do calendário para tráfego a partir da interface de reciclagem. Isso reflete o valor de largura de banda do calendário alocado na interface de reciclagem.
-
B2 – Peso de slot de calendário para tráfego de interfaces que não sejam a interface de reciclagem. Por exemplo, a interface NIF.
O mecanismo de reciclagem tem dois modos de operação:
-
Modo de reciclamento padrão de largura de banda
-
Modo de banda de reciclável configurável
Modo de reciclamento padrão de largura de banda
Como o nome sugere, o modo de largura de banda de ciclo padrão é habilitado por padrão e a configuração do usuário não é necessária. A interface de reciclagem é alocada em uma parte definida da largura de banda total do calendário. Essa largura de banda recyle é garantida e, portanto, é estável em tempos de congestionamento de tráfego. Os aplicativos de reciclagem compartilham essa largura de banda na melhor base de esforço, o que significa que não há largura de banda garantida por aplicativo.
Os benefícios da largura de banda de ciclo padrão incluem:
-
Utilização eficiente da largura de banda do ciclo de ciclo. Caso nenhum aplicativo de reciclagem esteja sendo executado, a largura de banda não utilizado pode ser compartilhada entre aplicativos em execução de outras interfaces.
-
Utilização eficiente da largura de banda de chip. Caso as outras interfaces que não sejam a interface de reciclagem não estejam transportando tráfego, a largura de banda não utilizada pode ser usada pelos aplicativos de reciclagem.
Modo de banda de reciclável configurável
Ao configurar a interface de reciclagem com base em perfis, a largura de banda do aplicativo se torna gerenciável. Você pode garantir a alocação de largura de banda de ciclo para um aplicativo definindo-a em um perfil.
Os benefícios da largura de banda de ciclo configurável incluem:
-
Alocação de largura de banda garantida para um aplicativo de reciclamento definido.
-
Flexibilidade para mudar a alocação de largura de banda, o que ajuda você a priorizar a largura de banda do aplicativo.
Exemplo: configuração da largura de banda de ciclo
RESUMO Este exemplo mostra como gerenciar a largura de banda de ciclo por aplicativo.
Visão geral
Aplicações 1, 2, 3 e 4 são aplicativos de reciclagem que usam a interface de reciclagem. A Tabela 1 mostra nossos requisitos de largura de banda. Neste caso, queremos uma alocação garantida de 10% da largura de banda da interface recyle para o aplicativo 1 e 20% para o aplicativo 2. Os aplicativos 3 e 4 não são prioridade e nenhuma garantia é necessária.
| Reciclar o | valor da largura de banda necessário para o | aplicativo
|---|---|
| Aplicativo 1 | 10% |
| Aplicativo 2 | 20% |
| Aplicativo 3 | indefinido |
| Aplicativo 4 | indefinido |
Configure a largura de banda da interface de reciclamento
set system packet-forwarding-options recycle-bandwidth profile profile1set system packet-forwarding-options recycle-bandwidth-profile profile1 application1 10 application2 20
Verificação
| Tarefa de verificação | de comandos |
|---|---|
show system packet-forwarding-options recycle-bandwidth-profile |
A partir do modo operacional, execute o |
Verificando a largura de banda de ciclo por aplicativo
Propósito
Verificando a alocação de largura de banda de ciclo por aplicativo.
Ação
user@router> show system packet-forwarding-options recycle-bandwidth-profile Recycle Interface details: Total Bandwidth : 300 Gbps/Core PFE : 0 Application-Name | Core | Bandwidth(Kbps) | Port | VoQ | Profile ----------------------------------------------------------------------------- application1 0 30000000 234 1336 profile1 application2 0 60000000 242 1400 profile1 application3 0 105000000 243 1408 profile1 application4 0 105000000 245 1424 profile1 PFE : 1 Application-Name | Core | Bandwidth(Kbps) | Port | VoQ | Profile ----------------------------------------------------------------------------- application1 0 30000000 234 2880 profile1 application2 0 60000000 242 2944 profile1 application3 0 105000000 243 2952 profile1 application4 0 105000000 245 2968 profile1
Significado
A saída mostra a alocação de largura de banda de ciclo por aplicativo conforme configurada na seção anterior.
| Resultado | configurado em porcentagem de aplicativos | |
|---|---|---|
| aplicativo1 | 10 | 300 Gbps x 10% = 30 Gbps |
| aplicativo2 | 20 | 300 Gbps x 20% = 60 Gbps |
| aplicativo3 | não configurado | Largura de banda/número não utilizados de aplicativos de reciclamento não configurados. (300 x 70%) / 2 = 105 Gbps |
| aplicativo4 | não configurado | (300 x 70%) / 2 = 105 Gbps |