Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

BGP multiprotocolo

Entender o BGP multiprotocol

O BGP multiprotocol (MP-BGP) é uma extensão do BGP que permite que o BGP carregue informações de roteamento para várias camadas de rede e atenda às famílias. O MP-BGP pode transportar as rotas unicast usadas para roteamento multicast separadamente das rotas usadas para o encaminhamento ip unicast.

Para habilitar o MP-BGP, você configura o BGP para transportar informações de alcance da camada de rede (NLRI) para famílias de endereço que não sejam iPv4 unicast, incluindo a family inet declaração:

Para permitir que o MP-BGP carregue NLRI para a família de endereços IPv6, inclua a family inet6 declaração:

Somente nos roteadores, para permitir que o MP-BGP carregue o NLRI de rede privada virtual (VPN) de Camada 3 para a família de endereços IPv4, inclua a family inet-vpn declaração:

Somente nos roteadores, para permitir que o MP-BGP carregue o NLRI VPN de Camada 3 para a família de endereços IPv6, inclua a family inet6-vpn declaração:

Somente nos roteadores, para permitir que o MP-BGP carregue o NLRI VPN multicast para a família de endereços IPv4 e habilitar a sinalização VPN, inclua a family inet-mvpn declaração:

Para permitir que o MP-BGP carregue o NLRI VPN multicast para a família de endereços IPv6 e habilitar a sinalização VPN, inclua a family inet6-mvpn declaração:

Para obter mais informações sobre VPNs multicast multiprotocol baseadas em BGP, consulte o Guia de usuários do Junos OS Multicast Protocols.

Para obter uma lista de níveis de hierarquia nos quais você pode incluir essas declarações, consulte as seções de resumo da declaração para essas declarações.

Nota:

Se você alterar a família de endereços especificada no nível de [edit protocols bgp family] hierarquia, todas as sessões BGP atuais no dispositivo de roteamento serão retiradas e, em seguida, restabelecidas.

No Junos OS Release 9.6 e posterior, você pode especificar um valor de loops para uma família de endereços BGP específica.

Por padrão, os pares BGP transportam apenas rotas unicast usadas para fins de encaminhamento unicast. Para configurar os pares BGP para transportar apenas rotas multicast, especifique a opção multicast . Para configurar os pares BGP para transportar rotas unicast e multicast, especifique a opção any .

Quando o MP-BGP está configurado, o BGP instala as rotas MP-BGP em diferentes tabelas de roteamento. Cada tabela de roteamento é identificada pela família de protocolos ou indicador familiar de endereço (AFI) e por um identificador familiar de endereço subsequente (SAFI).

A lista a seguir mostra todas as combinações possíveis de AFI e SAFI:

  • AFI=1, SAFI=1, unicast IPv4

  • AFI=1, SAFI=2, multicast IPv4

  • AFI=1, SAFI=128, L3VPN IPv4 unicast

  • AFI=1, SAFI=129, multicast L3VPN IPv4

  • AFI=2, SAFI=1, IPv6 unicast

  • AFI=2, SAFI=2, multicast IPv6

  • AFI=25, SAFI=65, BGP-VPLS/BGP-L2VPN

  • AFI=2, SAFI=128, L3VPN IPv6 unicast

  • AFI=2, SAFI=129, multicast L3VPN IPv6

  • AFI=1, SAFI=132, restrição de RT

  • AFI=1, SAFI=133, Fluxo-especificação

  • AFI=1, SAFI=134, Fluxo-especificação

  • AFI=3, SAFI=128, CLNS VPN

  • AFI=1, SAFI=5, NG-MVPN IPv4

  • AFI=2, SAFI=5, NG-MVPN IPv6

  • AFI=1, SAFI=66, MDT-SAFI

  • AFI=1, SAFI=4, IPv4 rotulado

  • AFI=2, SAFI=4, IPv6 (6PE)

As rotas instaladas na tabela de roteamento inet.2 só podem ser exportadas para os pares MP-BGP porque usam o SAFI, identificando-os como rotas para fontes multicast. As rotas instaladas na tabela de roteamento inet.0 só podem ser exportadas para os pares BGP padrão.

A tabela de roteamento inet.2 deve ser um subconjunto das rotas que você tem no inet.0, uma vez que é improvável que você tenha uma rota para uma fonte multicast para a qual você não poderia enviar tráfego unicast. A tabela de roteamento inet.2 armazena as rotas unicast que são usadas para verificações de encaminhamento de caminho reverso multicast e as informações adicionais de alcance aprendidas pelo MP-BGP a partir das atualizações multicast NLRI. Uma tabela de roteamento inet.2 é criada automaticamente quando você configura MP-BGP (definindo NLRI para any).

Ao habilitar o MP-BGP, você pode fazer o seguinte:

Limitando o número de prefixos recebidos em uma sessão BGP Peer

Você pode limitar o número de prefixos recebidos em uma sessão de peer BGP, e registrar mensagens limitadas por taxa quando o número de prefixos injetados excede um limite definido. Você também pode derrubar o peering quando o número de prefixos exceder o limite.

Para configurar um limite para o número de prefixos que podem ser recebidos em uma sessão BGP, inclua a prefix-limit declaração:

Para obter uma lista de níveis de hierarquia nos quais você pode incluir esta declaração, consulte a seção de resumo da declaração para esta declaração.

Para maximum number, especifique um valor na faixa de 1 a 4.294.967.295. Quando o número máximo especificado de prefixos é excedido, uma mensagem de log do sistema é enviada.

Se você incluir a teardown declaração, a sessão será demolida quando o número máximo de prefixos for excedido. Se você especificar uma porcentagem, as mensagens são registradas quando o número de prefixos excede essa porcentagem do limite máximo especificado. Após a demolição da sessão, ela é restabelecida em pouco tempo (a menos que você inclua a idle-timeout declaração). Se você incluir a idle-timeout declaração, a sessão pode ser mantida baixa por um período especificado de tempo ou para sempre. Se você especificar forever, a sessão só será restabelecida após você emitir um clear bgp neighbor comando. Se você incluir a drop-excess <percentage> declaração e especificar uma porcentagem, o excesso de rotas é descartado quando o número de prefixos excede a porcentagem. Se você incluir a hide-excess <percentage> declaração e especificar uma porcentagem, as rotas em excesso ficam ocultas quando o número de prefixos excede a porcentagem. Se a porcentagem for modificada, as rotas serão reavaliadas automaticamente.

Nota:

No Junos OS Release 9.2 e posterior, você pode configurar alternativamente um limite para o número de prefixos que podem ser aceitos em uma sessão de peer BGP. Para obter mais informações, consulte Limitando o número de prefixos aceitos em uma sessão BGP Peer.

Limitando o número de prefixos aceitos em uma sessão BGP Peer

No Junos OS Release 9.2 e posterior, você pode limitar o número de prefixos que podem ser aceitos em uma sessão de peer BGP. Quando esse limite especificado é excedido, uma mensagem de log do sistema é enviada. Você também pode especificar para redefinir a sessão BGP se o limite para o número de prefixos especificados for excedido.

Para configurar um limite para o número de prefixos que podem ser aceitos em uma sessão de peer BGP, inclua a accepted-prefix-limit declaração:

Para obter uma lista de níveis de hierarquia nos quais você pode incluir esta declaração, consulte a seção de resumo da declaração para esta declaração.

Para maximum number, especifique um valor na faixa de 1 a 4.294.967.295.

Inclua a teardown declaração para redefinir a sessão de peer BGP quando o número de prefixos aceitos excede o limite configurado. Você também pode incluir um valor percentual de 1 a 100 para ter uma mensagem de log do sistema enviada quando o número de prefixos aceitos excede essa porcentagem do limite máximo. Por padrão, uma sessão BGP que é reiniciada é restabelecida em pouco tempo. Inclua a idle-timeout declaração para impedir que a sessão BGP seja restabelecida por um período de tempo especificado. Você pode configurar um valor de tempo limite de 1 a 2400 minutos. Inclua a opção forever de evitar que a sessão BGP seja restabelecida até que você emita o clear bgp neighbor comando. Se você incluir a drop-excess <percentage> declaração e especificar uma porcentagem, o excesso de rotas é descartado quando o número de prefixos excede a porcentagem. Se você incluir a hide-excess <percentage> declaração e especificar uma porcentagem, as rotas em excesso ficam ocultas quando o número de prefixos excede a porcentagem. Se a porcentagem for modificada, as rotas serão reavaliadas automaticamente.

Nota:

Quando o roteamento ativo (NSR) ininterrupto é ativado e ocorre uma transferência para um mecanismo de roteamento de backup, os pares BGP que estão em baixa são reiniciados automaticamente. Os pares são reiniciados mesmo que a idle-timeout forever declaração esteja configurada.

Nota:

Alternativamente, você pode configurar um limite para o número de prefixos que podem ser recebidos (em vez de aceitos) em uma sessão de peer BGP. Para obter mais informações, consulte Limitando o número de prefixos recebidos em uma sessão BGP Peer.

Configuração de grupos de tabela de roteamento BGP

Quando uma sessão BGP recebe um NLRI unicast ou multicast, ele instala a rota na tabela apropriada (inet.0 ou inet6.0 para unicast, e inet.2 ou inet6.2 para multicast). Para adicionar prefixos unicast às tabelas unicast e multicast, você pode configurar grupos de tabela de roteamento BGP. Isso é útil se você não puder realizar negociações de NLRI multicast.

Para configurar grupos de tabela de roteamento BGP, inclua a rib-group declaração:

Para obter uma lista de níveis de hierarquia nos quais você pode incluir esta declaração, consulte a seção de resumo da declaração para esta declaração.

Resolvendo rotas para dispositivos de roteamento PE localizados em outras ASs

Você pode permitir que rotas rotuladas sejam colocadas na inet.3 tabela de roteamento para resolução de rotas. Essas rotas são então resolvidas para conexões de dispositivo de roteamento de borda de provedor (PE), onde o PE remoto está localizado em outro sistema autônomo (AS). Para que um dispositivo de roteamento pe instale uma rota na instância de roteamento e encaminhamento vpn (VRF), o próximo salto deve resolver para uma rota armazenada dentro da inet.3 tabela.

Para resolver rotas na inet.3 tabela de roteamento, inclua a resolve-vpn declaração:

Para obter uma lista de níveis de hierarquia nos quais você pode incluir esta declaração, consulte a seção de resumo da declaração para esta declaração.

Permitindo rotas rotuladas e sem rótulos

Você pode permitir que rotas rotuladas e sem rótulos sejam trocadas em uma única sessão. As rotas rotuladas são colocadas na tabela de roteamento inet.3 ou inet6.3, e rotas unicast rotuladas e não rotuladas podem ser enviadas ou recebidas pelo dispositivo de roteamento.

Para permitir que rotas rotuladas e não rotuladas sejam trocadas, inclua a rib declaração:

Para obter uma lista de níveis de hierarquia nos quais você pode incluir esta declaração, consulte a seção de resumo da declaração para esta declaração.

Example: Configuração de rotas BGP IPv6 pelo transporte IPv4

Este exemplo demonstra como exportar prefixos IPv6 e IPv4 por uma conexão IPv4 onde ambos os lados estão configurados com uma interface IPv4.

Requisitos

Nenhuma configuração especial além da inicialização do dispositivo é necessária antes de configurar este exemplo.

Visão geral

Tenha em mente o seguinte ao exportar prefixos BGP IPv6:

  • O BGP deriva prefixos de next-hop usando o prefixo IPv4 mapeado IPv6. Por exemplo, o prefixo 10.19.1.1 de next-hop IPv4 se traduz no prefixo next-hop IPv6 ::ffff:10.19.1.1.1.

    Nota:

    Deve haver uma rota ativa para o IPv4 mapeado IPv6 próximo salto para exportar prefixos BGP IPv6.

  • Uma conexão IPv6 deve ser configurada pelo enlace. A conexão deve ser um túnel IPv6 ou uma configuração de pilha dupla. O empilhamento duplo é usado neste exemplo.

  • Ao configurar prefixos IPv6 mapeados pelo IPv4, use uma máscara com mais de 96 bits.

  • Configure uma rota estática se quiser usar prefixos IPv6 normais. Este exemplo usa rotas estáticas.

Figura 1 mostra a topologia da amostra.

Figura 1: Topologia para configurar rotas BGP IPv6 pelo transporte IPv4Topologia para configurar rotas BGP IPv6 pelo transporte IPv4

Cópia de

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 os detalhes necessários para combinar com a configuração de sua rede e, em seguida, copie e cole os comandos na CLI no nível de [edit] hierarquia.

Dispositivo R1

Dispositivo R2

Dispositivo R3

Configuração do dispositivo R1

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 pela CLI, consulte o uso do editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.

Para configurar o dispositivo R1:

  1. Configure as interfaces, incluindo um endereço IPv4 e um endereço IPv6.

  2. Configure EBGP.

  3. Habilite o BGP para transportar rotas unicast IPv4 e IPv6 unicast.

    As rotas unicast IPv4 são habilitadas por padrão. No entanto, quando você configura outras famílias de endereços NLRI, o unicast IPv4 deve ser configurado explicitamente.

  4. Configure a política de roteamento.

  5. Configure algumas rotas estáticas.

  6. Configure o número do sistema autônomo (AS).

Resultados

A partir do modo de configuração, confirme sua configuração entrando nosshow interfaces, show policy-optionsshow protocolse show routing-options comandos. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Se você terminar de configurar o dispositivo, entre no commit modo de configuração. Repita a configuração no dispositivo R2 e no dispositivo R3, alterando os nomes da interface e endereços IP, conforme necessário.

Verificação

Confirme que a configuração está funcionando corretamente.

Verificando o status do vizinho

Propósito

Certifique-se de que o BGP esteja habilitado para transportar rotas unicast IPv6.

Ação

Do modo operacional, entre no show bgp neighbor comando.

Significado

As várias ocorrências da inet6-unicast saída mostram que o BGP está habilitado a transportar rotas unicast IPv6.

Verificando a tabela de roteamento

Propósito

Certifique-se de que o dispositivo R2 tenha rotas BGP em sua tabela de roteamento inet6.0.

Ação

Do modo operacional, entre no show route protocol bgp inet6.0 comando.

Visão geral das rotas IPv4 publicitárias sobre o BGP IPv6 Sessions

Em uma rede IPv6, o BGP normalmente anuncia informações de alcance da camada de rede IPv6 em uma sessão IPv6 entre colegas BGP. Em versões anteriores, o Junos OS apoiava a troca de unicast inet6, inet6 multicast ou apenas famílias de endereço unicast de rótulo inet6. Esse recurso permite a troca de todas as famílias de endereços BGP. Em um ambiente de pilha dupla que tem IPv6 em seu núcleo. esse recurso permite que o BGP anuncie a alcance do unicast IPv4 com o IPv4 no próximo salto em uma sessão BGP IPv6.

Esse recurso é apenas para sessões BGP IPv6, onde o IPv4 está configurado em ambos os endpoints. Pode local-ipv4-address ser um endereço de loopback ou qualquer endereço ipv4 para uma sessão de IBGP ou EBGP de múltiplos hops. Para alto-falantes BGP externos de salto único que não fazem parte das confederações BGP, se o endereço IPv4 local configurado não estiver conectado diretamente, a sessão BGP é fechada e permanece ociosa e um erro é gerado, que é exibido na saída do show bgp neighbor comando.

Para habilitar a publicidade de rotas IPv4 na sessão IPv6, configure local-ipv4-address da seguinte forma:

Nota:

Você não pode configurar esse recurso para as famílias de endereços inet6 unicast, inet6 multicast ou inet6 labeled-unicast, porque o BGP já tem a capacidade de anunciar essas famílias de endereços em uma sessão BGP IPv6.

A configuração local-ipv4-address só é usada quando o BGP anuncia rotas com self-next hop. Quando o IBGP anuncia rotas aprendidas com os pares de EBGP ou o refletor de rota anuncia rotas BGP para seus clientes, o BGP não muda a rota do próximo salto, ignora os configurados local-ipv4-addresse usa o IPv4 original no próximo hop.

Example: Anunciando rotas IPv4 em sessões BGP IPv6

Este exemplo mostra como anunciar rotas IPv4 durante a sessão BGP IPv6. Em um ambiente de pilha dupla que tem iPv6 em seu núcleo, há a necessidade de alcançar hosts IPv4 remotos. Portanto, o BGP anuncia rotas IPv4 com o próximo hop IPv4 para os colegas BGP em sessões BGP usando endereços de origem e destino IPv6. Esse recurso permite que o BGP anuncie a alcance do unicast IPv4 com o IPv4 no próximo salto sobre sessões BGP IPv6.

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Três roteadores com capacidade de empilhamento duplo

  • Junos OS Versão 16.1 ou posterior em execução em todos os dispositivos

Antes de habilitar anúncios IPv4 em sessões BGP IPv6, certifique-se de:

  1. Configure as interfaces do dispositivo.

  2. Configure o empilhamento duplo em todos os dispositivos.

Visão geral

Começando com o lançamento de 16.1, o Junos OS permite que o BGP anuncie a acessibilidade unicast IPv4 com o próximo salto IPv4 em uma sessão BGP IPv6. Nos lançamentos anteriores do Junos OS, o BGP poderia anunciar apenas inet6 unicast, inet6 multicast e inet6 famílias de endereço unicast rotuladas em sessões BGP IPv6. Esse recurso permite que o BGP troque todas as famílias de endereços BGP por uma sessão IPv6. Você pode habilitar o BGP a anunciar rotas IPv4 com o próximo hop IPv4 para os pares BGP durante a sessão IPv6. A configuração local-ipv4-address só é usada quando o BGP anuncia rotas com self-next hop.

Nota:

Você não pode configurar esse recurso para as famílias de endereços inet6 unicast, inet6 multicast ou inet6 labeled-unicast, porque o BGP já tem a capacidade de anunciar essas famílias de endereços em uma sessão BGP IPv6.

Topologia

Em Figura 2, uma sessão BGP externa IPv6 está em execução entre roteadores R1 e R2. Uma sessão IPv6 IBGP está estabelecida entre o Roteador R2 e o Roteador R3. As rotas estáticas IPv4 são redistribuídas para o BGP no R1. Para redistribuir as rotas IPv4 na sessão BGP IPv6, o novo recurso deve ser habilitado em todos os roteadores no nível de [edit protocols bgp address family] hierarquia.

Figura 2: Anunciando rotas IPv4 em sessões BGP IPv6Anunciando rotas IPv4 em sessões BGP IPv6

Cópia de

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 sua configuração de rede, copiar e colar os comandos na CLI no nível de [edit] hierarquia e, em seguida, entrar no commit modo de configuração.

Roteador R1

Roteador R2

Roteador R3

Configuração do roteador R1

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 pela CLI, consulte o uso do Editor de CLI no modo de configuração no guia de usuário da CLI.

Para configurar o roteador R1:

Nota:

Repita este procedimento para outros roteadores depois de modificar os nomes, endereços e outros parâmetros de interface apropriados.

  1. Configure as interfaces com endereços IPv4 e IPv6.

  2. Configure o endereço de loopback.

  3. Configure uma rota estática IPv4 que precisa ser anunciada.

  4. Configure o sistema autônomo para hosts BGP.

  5. Configure o EBGP nos roteadores de borda externos.

  6. Habilite o recurso para anunciar o adddress IPv4 140.1.1.1 em sessões BGP IPv6.

  7. Defina uma política p1 para aceitar todas as rotas estáticas.

  8. Aplique a política p1 no grupo EBGP ebgp-v6.

Resultados

A partir do modo de configuração, confirme sua configuração entrando nosshow interfaces, show protocolsshow routing-optionse show policy-options comandos. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Se você terminar de configurar o dispositivo, comprometa a configuração.

Verificação

Confirme que a configuração está funcionando corretamente.

Verificando se a sessão BGP está ativa

Propósito

Verifique se o BGP está em execução nas interfaces configuradas e se a sessão BGP está ativa para cada endereço vizinho.

Ação

Do modo operacional, execute o show bgp summary comando no roteador R1.

Significado

A sessão BGP está em funcionamento, e o peering BGP está estabelecido.

Verificando se o endereço IPv4 está sendo anunciado

Propósito

Verifique se o endereço IPv4 configurado está sendo anunciado pelo Roteador R1 para os vizinhos BGP configurados.

Ação

Do modo operacional, execute o show route advertising-protocol bgp ::150.1.1.2 comando no roteador R1.

Significado

A rota estática IPv4 está sendo anunciada para o roteador vizinho BGP R2.

Verificando se o roteador vizinho BGP R2 recebe o endereço IPv4 anunciado

Propósito

Verifique se o roteador R2 recebe o endereço IPv4 que o Roteador R1 está anunciando ao vizinho BGP por IPv6.

Ação
Significado

A presença da rota IPv4 estática na tabela de roteamento do Roteador R2 indica que ele está recebendo as rotas IPv4 anunciadas do Roteador R1.

Entender a redistribuição das rotas IPv4 com o IPv6 Next Hop no BGP

Em uma rede que transporta predominantemente o tráfego IPv6, há a necessidade de rotear rotas IPv4 quando necessário. Por exemplo, um provedor de serviços de Internet que tem uma rede somente IPv6, mas tem clientes que ainda roteam o tráfego IPv4. Nesse caso, é necessário atender a esses clientes e encaminhar o tráfego IPv4 por uma rede IPv6. Conforme descrito no RFC 5549, as informações de alcance da camada de rede IPv4 com um tráfego IPv6 Next Hop IPv4 são enviadas de dispositivos de equipamentos de instalações do cliente (CPE) para gateways IPv4-over-IPv6. Esses gateways são anunciados para dispositivos CPE por meio de endereçoscast. Os dispositivos de gateway criam túneis IPv4-over-IPv6 dinâmicos para dispositivos CPE remotos e anunciam rotas agregadas IPv4 para direcionar o tráfego.

Nota:

O recurso dinâmico de túnel IPv4-over-IPv6 não oferece suporte a ISSU unificado no Junos OS Release 17.3R1.

Os refletores de roteamento (RRs) com uma interface programável são conectados pelo IBGP aos roteadores de gateway e rotas de hospedagem com endereço IPv6 como o próximo salto. Esses RRs anunciam os endereços IPv4/32 para injetar as informações do túnel na rede. Os roteadores de gateway criam túneis IPv4-over-IPv6 dinâmicos para a borda remota do provedor de clientes. O roteador de gateway também anuncia as rotas agregadas IPv4 para direcionar o tráfego. O RR anuncia então as rotas de origem do túnel para o ISP. Quando o RR remove a rota do túnel, o BGP também retira a rota fazendo com que o túnel seja derrubado e o CPE seja inalcançável. O roteador de gateway também retira as rotas agregadas IPv4 e as rotas de origem de túnel IPv6 quando todas as rotas agregadas de contribuição de rotas são removidas. O roteador de gateway envia a retirada da rota quando a placa de linha âncora do Mecanismo de Encaminhamento de Pacotes diminuir, para que ele redirecione o tráfego para outros roteadores de gateway.

As seguintes extensões são introduzidas para dar suporte a rotas IPv4 com um próximo hop IPv6:

Codificação bgp next hop

O BGP é estendido com o recurso de codificação next hop que é usado para enviar rotas IPv4 com iPv6 next hops. Se esse recurso não estiver disponível no peer remoto, o BGP agrupa os pares com base nesse recurso de codificação e remove a família BGP sem codificar recursos da lista de informações de alcance da camada de rede negociada (NLRI). O Junos OS permite apenas uma tabela de resolução, como o inet.0. Para permitir rotas BGP IPv4 com o BGP IPv6 next hops cria uma nova árvore de resolução. Esse recurso permite que uma tabela de roteamento do Junos OS tenha várias árvores de resolução.

Além do RFC 5549, a publicidade IPv4 Network Layer Reachability Information com um IPv6 Next Hop uma nova comunidade de encapsulamento especificada no RFC 5512, o BGP Encapsulation Subsequent Address Family Identifier (SAFI) e o BGP Tunnel Encapsulation Attribute são introduzidos para determinar a família de endereços do endereço next-hop. A comunidade de encapsulamento indica o tipo de túneis que o nó de entrada precisa criar. Quando o BGP recebe rotas IPv4 com endereço IPv6 next hop e a comunidade de encapsulamento V4oV6, o BGP cria túneis dinâmicos IPv4-over-IPv6. Quando o BGP recebe rotas sem a comunidade de encapsulamento, as rotas BGP são resolvidas sem criar o túnel V4oV6.

Uma nova ação dynamic-tunnel-attributes dyan-attribute de política está disponível no nível da [edit policy-statement policy name term then] hierarquia para dar suporte ao novo encapsulamento estendido.

Localização de túneis

A infraestrutura dinâmica de túneis é aprimorada com a localização de túneis para oferecer suporte a um número maior de túneis. Existe a necessidade de localização de túneis para fornecer resiliência para lidar com o tráfego quando a âncora falha. Um ou mais chassis fazem backup uns dos outros e deixam o processo de protocolo de roteamento (rpd) afastar o tráfego do ponto de falha para o chassi de backup. O chassi anuncia apenas esses prefixos agregados em vez dos endereços de loopback individuais na rede.

Tratamento de túneis

O IPv4 sobre túneis IPv6 usa a infraestrutura dinâmica de túnel, juntamente com a ancoragem de túnel para dar suporte à ampla escala de chassi necessária. O estado do túnel é localizado em um mecanismo de encaminhamento de pacotes e os outros mecanismos de encaminhamento de pacotes direcionam o tráfego até a âncora do túnel.

Entrada de túnel

A entrada de túnel ou encapsulamento de túnel encaminha o tráfego de rede em direção ao local do cliente. Quando o estado do túnel está presente no mecanismo de encaminhamento de pacotes no qual o tráfego entrou no chassi, o processo de protocolo de roteamento (rpd) usa o seguinte procedimento para redistribuir rotas IPv4 em túneis IPv6:
Figura 3: Tratamento de entrada de túnel quando o estado do túnel estiver disponível no mesmo PFETratamento de entrada de túnel quando o estado do túnel estiver disponível no mesmo PFE
Figura 4: Tratamento de entrada de túnel quando o estado do túnel está em um PFE diferenteTratamento de entrada de túnel quando o estado do túnel está em um PFE diferente
  1. Encapsula o tráfego IPv4 dentro do cabeçalho IPv6.

    A aplicação máxima da unidade de transmissão (MTU) é realizada antes do encapsulamento. Se o tamanho do pacote encapsulado exceder o MTU do DF-bit túnel e os pacotes IPv4 não forem definidos, o pacote será fragmentado e esses fragmentos serão encapsulados.

  2. Usa balanceamento de carga de tráfego baseado em hash em cabeçalhos internos de pacotes.

  3. Encaminha o tráfego para o endereço IPv6 de destino. O endereço IPv6 é retirado do cabeçalho IPv6.

Saída de túnel

A saída do túnel encaminha o tráfego do equipamento das instalações do cliente para o lado da rede.
Figura 5: Tratamento de saída de túnel quando o estado do túnel estiver disponível no mesmo PFETratamento de saída de túnel quando o estado do túnel estiver disponível no mesmo PFE
Figura 6: Tratamento de saída de túnel quando o estado do túnel estiver disponível em um PFE remotoTratamento de saída de túnel quando o estado do túnel estiver disponível em um PFE remoto
  1. Descapsula o pacote IPv4 presente no pacote IPv6.

  2. Realiza verificações anti-spoof para garantir que o par IPv6 e IPv4 combine com as informações usadas para configurar o túnel.

  3. Procure o endereço de destino IPv4 a partir do cabeçalho IPv4 do pacote descapsulado e encaminhe o pacote para o endereço IPv4 especificado.

Balanceamento de carga de túnel e tratamento de falha no mecanismo de encaminhamento de pacotes âncora

A falha do mecanismo de encaminhamento de pacotes precisa ser tratada prontamente para evitar a filtragem de rotas nulas do tráfego de túnel ancorado no Mecanismo de Encaminhamento de Pacotes. A localização do túnel envolve o uso de anúncios BGP para reparar a falha globalmente. O tráfego do túnel é desviado do ponto de falha para outro chassi de backup que contém o estado de túnel idêntico. Para balanceamento de carga de tráfego, o chassi está configurado para anunciar diferentes valores discriminatórios de múltiplas saídas (MED) para cada um dos conjuntos de prefixo, de modo que apenas o tráfego para um quarto dos túneis passe por cada chassi. O tráfego de CPE também é tratado de maneira semelhante, configurando o mesmo conjunto de endereços anycast em cada chassi e direcionando apenas um quarto do tráfego em direção a cada chassi.

O Anchor Packet Forwarding Engine é a única entidade que faz todo o processamento para um túnel. A seleção do mecanismo de encaminhamento de pacotes âncora é por meio de provisionamento estático e vinculado às interfaces físicas do Packet Forwarding Engine. Quando um dos mecanismos de encaminhamento de pacotes cai, o daemon marca todos os mecanismos de encaminhamento de pacotes na placa de linha e comunica essas informações ao processo de protocolo de roteamento do protocolo de roteamento e outros daemons. O processo de protocolo de roteamento envia saques BGP para os prefixos ancorados no mecanismo de encaminhamento de pacotes com falha e nos endereços IPv6 atribuídos ao Mecanismo de Encaminhamento de Pacotes que está desligado. Esses anúncios redirecionam o tráfego para outros chassis de backup. Quando o mecanismo de encaminhamento de pacotes falhou novamente, o chassi marca o Mecanismo de Encaminhamento de Pacotes como up e atualiza o processo de protocolo de roteamento. O processo de protocolo de roteamento desencadeia atualizações BGP para seus pares de que túneis ancorados no mecanismo de encaminhamento de pacotes específico estão agora disponíveis para tráfego de roteamento. Esse processo pode levar minutos para a configuração de túnel em grande escala. Portanto, o Ack mecanismo é integrado ao sistema para garantir uma perda mínima de tráfego enquanto comuta o tráfego de volta para o chassi original.

Estatísticas do fluxo de loopback de túnel

A infraestrutura dinâmica de túnel usa fluxos de loopback no Packet Forwarding Engine para looping do pacote após o encapsulamento. Como a largura de banda deste fluxo de loopback é limitada, é necessário monitorar o desempenho de fluxos de loopback de túnel.

Para monitorar as estatísticas do fluxo de loopback, use o comando show pfe statistics traffic detail operacional que exibe as estatísticas agregadas de fluxo de loopback, incluindo taxa de encaminhamento, taxa de pacotes de queda e taxa de byte.

Configuração do BGP para redistribuir rotas IPv4 com endereços IPv6 Next-Hop

A partir do lançamento do 17.3R1, os dispositivos Junos OS podem encaminhar o tráfego IPv4 por uma rede somente IPv6, que geralmente não pode encaminhar o tráfego IPv4. Como descrito no RFC 5549, o tráfego IPv4 é tunelado de dispositivos CPE para gateways IPv4-over-IPv6. Esses gateways são anunciados para dispositivos CPE por meio de endereçoscast. Os dispositivos de gateway criam túneis IPv4-over-IPv6 dinâmicos para equipamentos remotos nas instalações do cliente e anunciam rotas agregadas IPv4 para direcionar o tráfego. Refletores de roteamento com interfaces programáveis injetam as informações do túnel na rede. Os refletores de rota são conectados pelo IBGP a roteadores de gateway, que anunciam os endereços IPv4 de rotas de host com endereços IPv6 como o próximo salto.

Nota:

O recurso dinâmico de túnel IPv4-over-IPv6 não oferece suporte a ISSU unificado no Junos OS Release 17.3R1.

Antes de começar a configurar o BGP para distribuir rotas IPv4 com endereços IPv6 next-hop, faça o seguinte:

  1. Configure as interfaces do dispositivo.

  2. Configure o OSPF ou qualquer outro protocolo IGP.

  3. Configure MPLS e LDP.

  4. Configure BGP.

Para configurar o BGP para distribuir rotas IPv4 com endereços IPv6 next-hop:

  1. Configure a opção de codificação de next-hop estendida para grupos BGP com pares IPv6 para rotear famílias de endereço IPv4 em uma sessão IPv6.
  2. Configure túneis IPv4-over-IPv6 dinâmicos e defina seus atributos para encaminhar o tráfego IPv4 em uma rede somente IPv6. O tráfego IPv4 é tunelado de dispositivos CPE para gateways IPv4-over-IPv6.
  3. Configure os atributos do túnel.

    Por exemplo, configure um túnel dinâmico com first_tunnel os seguintes atributos:

  4. Defina uma política para associar o perfil de atributo de túnel dinâmico configurado a uma lista de prefixo ou a um filtro de rota.

    Por exemplo, definir dynamic_tunnel_policy política para associar os atributos dinâmicos do túnel first_tunnel apenas ao tráfego que vai para uma rota específica 2.2.2.2/32.

  5. Exporte a política definida.

    Por exemplo, exporte a política configurada dynamic_tunnel_policy .

Habilitando a sinalização vpn e VPLS de Camada 2

Você pode permitir que o BGP carregue mensagens DE VPN e VPLS NLRI de Camada 2.

Para habilitar a sinalização VPN e VPLS, inclua a family declaração:

Para obter uma lista de níveis de hierarquia nos quais você pode incluir esta declaração, consulte a seção de resumo da declaração para esta declaração.

Para configurar um número máximo de prefixos, inclua a prefix-limit declaração:

Para obter uma lista de níveis de hierarquia nos quais você pode incluir esta declaração, consulte a seção de resumo da declaração para esta declaração.

Quando você define o número máximo de prefixos, uma mensagem é registrada quando esse número é atingido. Se você incluir a teardown declaração, a sessão será demolida quando o número máximo de prefixos for atingido. Se você especificar uma porcentagem, as mensagens são registradas quando o número de prefixos atinge essa porcentagem. Uma vez que a sessão é demolida, ela é restabelecida em pouco tempo. Inclua a idle-timeout declaração para manter a sessão baixa por um tempo especificado ou para sempre. Se você especificar forever, a sessão só será restabelecida depois de usar o clear bgp neighbor comando. Se você incluir a drop-excess <percentage> declaração e especificar uma porcentagem, o excesso de rotas é descartado quando o número de prefixos excede a porcentagem. Se você incluir a hide-excess <percentage> declaração e especificar uma porcentagem, as rotas em excesso ficam ocultas quando o número de prefixos excede a porcentagem. Se a porcentagem for modificada, as rotas serão reavaliadas automaticamente.

Entender as rotas de fluxo BGP para filtragem de tráfego

Uma rota de fluxo é uma agregação de condições de correspondência para pacotes IP. As rotas de fluxo são instaladas como filtros de tabela de encaminhamento de entrada (implícitos) e são propagadas pela rede usando mensagens de informações de alcance da camada de rede (NLRI) de especificação de fluxo e instaladas na tabela instance-name.inetflow.0de roteamento de fluxo. Os pacotes só podem viajar por rotas de fluxo se as condições específicas de correspondência forem atendidas.

As rotas de fluxo e os filtros de firewall são semelhantes, na medida em que filtram pacotes com base em seus componentes e realizam uma ação nos pacotes compatíveis. As rotas de fluxo fornecem recursos de filtragem de tráfego e limitação de taxa, assim como filtros de firewall. Além disso, você pode propagar rotas de fluxo em diferentes sistemas autônomos.

As rotas de fluxo são propagadas pelo BGP por meio de mensagens NLRI de especificação de fluxo. Você deve habilitar o BGP a propagar essas NLRIs.

A partir do Junos OS Release 15.1, as mudanças são implementadas para estender o suporte ininterrupto de roteamento ativo (NSR) para famílias existentes de fluxo de inetvpn e fluxo de inetvpn e estender a validação de rotas para fluxo BGP por draft-ietf-idr-bgp-flowspec-oid-01. Duas novas declarações são introduzidas como parte desse aprimoramento. Veja enforce-first-as e no-install.

Nota:

Começando pelo Junos OS Release 16.1, o suporte ao IPv6 é estendido à especificação de fluxo BGP que permite a propagação de regras de especificação de fluxo de tráfego para pacotes IPv6 e VPN-IPv6. A especificação de fluxo BGP automatiza a coordenação das regras de filtragem de tráfego, a fim de mitigar o ataque distribuído de negação de serviço durante o roteamento ativo (NSR) sem parar.

Começando pelo Junos OS Release 16.1R1, a especificação de fluxo BGP oferece suporte à ação de filtragem de marcação extended-community de tráfego. Para tráfego IPv4, o Junos OS modifica os bits de ponto de código DiffServ (DSCP) de um pacote IPv4 em trânsito para o valor correspondente da comunidade estendida. Para pacotes IPv6, o Junos OS modifica os primeiros seis bits do traffic class campo do pacote IPv6 transmissor para o valor correspondente da comunidade estendida.

A partir do Junos OS Release 17.1R1, O BGP pode levar informações de alcance da camada de rede (NLRI) de especificação de fluxo em roteadores da Série PTX que têm FPCs de terceira geração (FPC3-PTX-U2 e FPC3-PTX-U3 no PTX5000 e FPC3-SFF-PTX-U0 e FPC3-SFF-PTX-U1 no PTX3000) instalados. Propagar informações de filtro de firewall como parte do BGP permite que você propagar filtros de firewall contra ataques de negação de serviço (DOS) dinamicamente em sistemas autônomos.

A partir do Junos OS Release 17.2R1, o BGP pode levar mensagens de informações de alcance da camada de rede (NLRI) de especificações de fluxo em roteadores PTX1000 que têm FPCs de terceira geração instalados. Propagar informações de filtro de firewall como parte do BGP permite que você propagar filtros de firewall contra ataques de negação de serviço (DOS) dinamicamente em sistemas autônomos.

A partir do lançamento do cRPD 20.3R1, as rotas de fluxo e as regras de policiamento propagadas pela especificação de fluxo BGP NLRI são baixadas para o kernel Linux por meio da estrutura do Linux Netfilter em ambientes cRPD.

Condições de correspondência para rotas de fluxo

Você especifica condições que o pacote deve combinar antes que a ação na then declaração seja tomada para uma rota de fluxo. Todas as condições da from declaração devem corresponder à ação a ser tomada. A ordem na qual você especifica condições de correspondência não é importante, porque um pacote deve combinar todas as condições em um termo para que uma correspondência ocorra.

Para configurar uma condição de correspondência, inclua a match declaração no nível de [edit routing-options flow] hierarquia.

Tabela 1 descreve as condições de correspondência da rota de fluxo.

Tabela 1: Condições de correspondência da rota de fluxo

Condição de correspondência

Descrição

destination prefix prefix-offset number

Campo de endereço de destino IP.

Você pode usar o prefix-offset campo opcional, que está disponível apenas em dispositivos Junos com MPCs aprimorados que estão configurados para o modo, para enhanced-ip especificar o número de bits que devem ser ignorados antes que o Junos OS comece a combinar com um prefixo IPv6.

destination-port number

Campo de porta de destino do TCP ou do Protocolo de Datagram do Usuário (UDP). Você não pode especificar as port condições e destination-port as condições de correspondência no mesmo termo.

No lugar do valor numérico, você pode especificar um dos seguintes sinônimos de texto (os números da porta também estão listados): afs(1483), bgp (179), biff (512), bootpc (68), bootps (67), cmd (514), cvspserver (2401), dhcp (67), domain (53), (21) eklogin 05), ekshell (2106), exec (512), finger (79), ftp (21), ftp-data (20), http (80), https (443), ident (113), imap (143), kerberos-sec (88), klogin (543), kpasswd (761), krb-prop (754), krbupdate (760), kshell (544), ldap (389), login (513), mobileip-agent (434), mobilip-mn (435), msdp (639), netbios-dgm (138), netbios-ns (137), netbios-ssn (139), (2049), nfsdnntp (119), ntalk (518), ntp (123), (123), pop3 (110), pptp (1723), printer (515), radacct (1813), radius (1812), rip (520), rkinit (2108), smtp (25), snmp (161), snmptrap (162), snpp (444), (108) socks 0), ssh (22), sunrpc (111), syslog (514), tacacs-ds (65), talk (517), telnet (23), tftp (69), timed (525), who (513), xdmcp (177), zephyr-clt (2103) ou zephyr-hm (2104).

dscp number

Ponto de código de serviços diferenciados (DSCP). O protocolo DiffServ usa o byte do tipo de serviço (ToS) no cabeçalho IP. Os seis bits mais significativos deste byte formam o DSCP.

Você pode especificar DSCP em forma hexadecimal ou decimal.

flow-label numeric-expression

Corresponda ao valor do rótulo de fluxo. O valor deste campo varia de 0 a 1048575.

Esta condição de correspondência é suportada apenas em dispositivos Junos com MPCs aprimorados que estão configurados para enhanced-ip o modo. Esta condição de correspondência não é suportada para IPv4.

fragment type

Campo do tipo fragmento. As palavras-chave são agrupadas pelo tipo de fragmento com o qual estão associadas:

  • dont-fragment

    Nota:

    Essa opção não tem suporte para IPv6.

  • first-fragment

  • is-fragment

  • last-fragment

  • not-a-fragment

Essa condição de correspondência é suportada apenas em dispositivos Junos OS com MPCs aprimorados que estão configurados para enhanced-ip o modo.

icmp-code numbericmp6-code icmp6-code-value;

Campo de código ICMP. Esse valor ou palavra-chave fornece informações mais específicas do que icmp-type. Como o significado do valor depende do valor associado icmp-type , você deve especificar icmp-type junto com icmp-code.

No lugar do valor numérico, você pode especificar um dos seguintes sinônimos de texto (os valores de campo também estão listados). As palavras-chave são agrupadas pelo tipo ICMP com o qual estão associadas:

  • problema de parâmetro: ip-header-bad (0), required-option-missing (1)

  • Redirecionar: redirect-for-host(1), redirect-for-network (0), redirect-for-tos-and-host (3), redirect-for-tos-and-net (2)

  • tempo excedido: ttl-eq-zero-during-reassembly(1), ttl-eq-zero-during-transit (0)

  • Inacessível: communication-prohibited-by-filtering(13), destination-host-prohibited (10), destination-host-unknown (7), destination-network-prohibited (9), destination-network-unknown (6), fragmentation-needed (4), host-precedence-violation (14), host-unreachable (1), host-unreachable-for-TOS (12), network-unreachable (0), network-unreachable-for-TOS (11), port-unreachable (3), precedence-cutoff-in-effect (15), protocol-unreachable (2), source-host-isolated (8), source-route-failed (5)

icmp-type number icmp6-type icmp6-type-value

Campo do tipo de pacote ICMP. Normalmente, você especifica esta correspondência em conjunto com a declaração de protocol correspondência para determinar qual protocolo está sendo usado na porta.

No lugar do valor numérico, você pode especificar um dos seguintes sinônimos de texto (os valores de campo também estão listados): echo-reply(0), echo-request (8), info-reply (16), info-request (15), mask-request (17), mask-reply (18), parameter-problem (12), redirect (5), router-advertisement (9), router-solicit (10), source-quench (4), time-exceeded (11), timestamp (13), timestamp-reply (14) ou unreachable (3).

packet-length number

Comprimento total do pacote IP.

port number

TCP ou UDP de origem ou campo de porta de destino. Você não pode especificar a port correspondência e a destination-port condição ou source-port a condição de correspondência no mesmo termo.

No lugar do valor numérico, você pode especificar um dos sinônimos de texto listados em destination-port.

protocol number

Campo de protocolo IP. No lugar do valor numérico, você pode especificar um dos seguintes sinônimos de texto (os valores de campo também estão listados): ah, egp(8), esp (50), gre (47), icmp (1), igmp (2), ipip (4), ipv6 (41), ospf (89), pim (103), rsvp (46), tcp (6) ou udp (17).

Esta condição de correspondência é suportada apenas para IPv6 em dispositivos Junos com MPCs aprimorados que estão configurados para enhanced-ip o modo.

source prefixprefix-offset number

Campo de endereço de origem IP.

Você pode usar o prefix-offset campo opcional, que está disponível apenas em dispositivos Junos com MPCs aprimorados que estão configurados para o modo, para enhanced-ip especificar o número de bits que devem ser ignorados antes que o Junos OS comece a combinar com um prefixo IPv6.

source-port number

Campo de porta de origem TCP ou UDP. Você não pode especificar as port condições e source-port combinar no mesmo termo.

No lugar do campo numérico, você pode especificar um dos sinônimos de texto listados em destination-port.

tcp-flag type

Formato de cabeçalho TCP.

Ações para rotas de fluxo

Você pode especificar a ação a tomar se o pacote corresponde às condições configuradas na rota de fluxo. Para configurar uma ação, inclua a then declaração no nível de [edit routing-options flow] hierarquia.

Tabela 2 descreve as ações da rota de fluxo.

Tabela 2: Modificadores de ação de rota de fluxo

Modificador de ação ou ação

Descrição

Ações

accept

Aceite um pacote. Esse é o padrão.

discard

Descarte um pacote silenciosamente, sem enviar uma mensagem do Protocolo de Mensagens de Controle de Internet (ICMP).

community

Substitua todas as comunidades da rota pelas comunidades especificadas.

Mark value

Defina um valor de DSCP para o tráfego que corresponda a esse fluxo. Especifique um valor de 0 a 63. Essa ação é suportada apenas em dispositivos Junos com MPCs aprimorados que estão configurados para enhanced-ip o modo.

next term

Continue até a próxima condição de jogo para avaliação.

routing-instance extended-community

Especifique uma instância de roteamento para a qual os pacotes são encaminhados.

rate-limit bits-per-second

Limite a largura de banda na rota de fluxo. Expresse o limite em bits por segundo (bps). Começando com o Junos OS Release 16.1R4, a faixa de limite de taxa é [0 a 10000000000].

sample

Experimente o tráfego na rota de fluxo.

Validação de rotas de fluxo

O Junos OS instala rotas de fluxo na tabela de roteamento de fluxo apenas se forem validadas usando o procedimento de validação. O mecanismo de roteamento faz a validação antes da instalação de rotas na tabela de roteamento de fluxo.

As rotas de fluxo recebidas usando as mensagens de informações de alcance da camada de rede BGP (NLRI) são validadas antes de serem instaladas na tabela de roteamento de instâncias primárias instance.inetflow.0de fluxo. O procedimento de validação é descrito no draft-ietf-idr-flow-spec-09.txt, Disseminação de Regras de Especificação de Fluxo. Você pode contornar o processo de validação de rotas de fluxo usando mensagens BGP NLRI e usar sua própria política de importação específica.

Para rastrear as operações de validação, inclua a validation declaração no nível de [edit routing-options flow] hierarquia.

Suporte para o algoritmo de especificação de fluxo BGP Versão 7 e posterior

Por padrão, o Junos OS usa o algoritmo de pedido de prazo definido na versão 6 do draft de especificação de fluxo BGP. No Junos OS Release 10.0 e posterior, você pode configurar o roteador para cumprir o algoritmo de pedidos de prazo definido pela primeira vez na versão 7 da especificação de fluxo BGP e suportado através do RFC 5575, disseminação de rotas de especificação de fluxo.

práticas recomendadas:

Recomendamos que você configure o Junos OS para usar o algoritmo de pedidos de prazo definido pela primeira vez na versão 7 do draft de especificação de fluxo BGP. Também recomendamos que você configure o Junos OS para usar o mesmo algoritmo de pedido de termo em todas as instâncias de roteamento configuradas em um roteador.

Para configurar o BGP para usar o algoritmo de especificação de fluxo definido pela primeira vez na versão 7 do draft da Internet, inclua a standard declaração no nível de [edit routing-options flow term-order] hierarquia.

Para voltar a usar o algoritmo de pedido de prazo definido na versão 6, inclua a legacy declaração no nível da [edit routing-options flow term-order] hierarquia.

Nota:

A ordem de termo configurada tem apenas significado local. Ou seja, o termo ordem não se propaga com rotas de fluxo enviadas para os pares BGP remotos, cuja ordem de termo é completamente determinada pela configuração de pedidos de prazo próprio. Portanto, você deve ter cuidado ao configurar a ação next term dependente de pedidos quando não estiver ciente da configuração do termo ordem dos pares remotos. O local next term pode diferir da next term configuração no peer remoto.

Nota:

No Junos OS Evolved, next term não pode aparecer como o último termo da ação. Um termo de filtro em que next term é especificado como uma ação, mas sem qualquer condição de correspondência configurada não é suportado.

A partir do Junos OS Release 16.1, você tem a opção de não aplicar o flowspec filtro ao tráfego recebido em interfaces específicas. Um novo termo é adicionado no início do flowspec filtro que aceita qualquer pacote recebido nessas interfaces específicas. O novo termo é uma variável que cria uma lista de exclusão de termos conectados ao filtro da tabela de encaminhamento como parte do filtro de especificação de fluxo.

Para excluir o flowspec filtro de ser aplicado ao tráfego recebido em interfaces específicas, você deve primeiro configurar uma group-id nessas interfaces, incluindo a declaração do grupo group-id do filtro da família inet no nível de [edit interfaces] hierarquia e, em seguida, anexar o flowspec filtro ao grupo de interface, incluindo a flow interface-group group-id exclude declaração no nível de [edit routing-options] hierarquia. Você pode configurar apenas uma group-id por instância de roteamento com a set routing-options flow interface-group group-id declaração.

Example: Permitindo que o BGP carregue rotas de especificação de fluxo

Este exemplo mostra como permitir que o BGP carregue mensagens de informações de alcance de camada de rede (NLRI) de especificação de fluxo.

Requisitos

Antes de começar:

  • Configure as interfaces do dispositivo.

  • Configure um protocolo de gateway interior (IGP).

  • Configure BGP.

  • Configure uma política de roteamento que exporta rotas (como rotas diretas ou rotas de IGP) da tabela de roteamento para o BGP.

Visão geral

Propagar informações de filtro de firewall como parte do BGP permite que você propagar filtros de firewall contra ataques de negação de serviço (DOS) dinamicamente em sistemas autônomos. As rotas de fluxo são encapsuladas no NLRI de especificação de fluxo e propagadas por uma rede ou redes privadas virtuais (VPNs), compartilhando informações semelhantes a filtros. As rotas de fluxo são uma agregação de condições de correspondência e ações resultantes para pacotes. Eles fornecem recursos de filtragem de tráfego e limitação de taxa, como filtros de firewall. As rotas de fluxo unicast são suportadas para a instância padrão, instâncias de roteamento e encaminhamento de VPN (VRF) e instâncias de roteador virtual.

Políticas de importação e exportação podem ser aplicadas ao NLRI familiar inet flow ou familiar inet-vpn flow , afetando as rotas de fluxo aceitas ou anunciadas, semelhante à forma como as políticas de importação e exportação são aplicadas a outras famílias BGP. A única diferença é que a configuração da política de fluxo deve incluir a declaração.rib inetflow.0 Esta declaração faz com que a política seja aplicada às rotas de fluxo. Uma exceção a esta regra ocorre se a política tiver apenas a then reject declaração ou a then accept declaração e nenhuma from declaração. Em seguida, a política afeta todas as rotas, incluindo ip unicast e fluxo ip.

Os filtros de rota de fluxo são configurados primeiro em um roteador estaticamente, com um conjunto de critérios de correspondência seguidos pelas ações a serem tomadas. Em seguida, além family inet unicastde , family inet flow (ou family inet-vpn flow) está configurado entre este dispositivo habilitado para BGP e seus pares.

Por padrão, as rotas de fluxo configuradas estaticamente (filtros de firewall) são anunciadas para outros dispositivos habilitados para BGP que oferecem suporte ao family inet flow NLRI.family inet-vpn flow

O dispositivo habilitado para BGP recebendo executa um processo de validação antes de instalar o filtro de firewall na tabela instance-name.inetflow.0de roteamento de fluxo. O procedimento de validação é descrito no RFC 5575, Disseminação de Regras de Especificação de Fluxo.

O dispositivo habilitado para BGP recebendo aceita uma rota de fluxo se passar pelos seguintes critérios:

  • O originador de uma rota de fluxo combina com o criador da melhor rota unicast de correspondência para o endereço de destino incorporado na rota.

  • Não existem rotas unicast mais específicas, quando comparadas com o endereço de destino da rota de fluxo, para a qual a rota ativa foi recebida de um sistema autônomo de next-hop diferente.

O primeiro critério garante que o filtro esteja sendo anunciado pelo next-hop usado pelo encaminhamento unicast para o endereço de destino incorporado na rota de fluxo. Por exemplo, se uma rota de fluxo for dada como 10.1.1.1, proto=6, port=80, o dispositivo habilitado para BGP recebendo seleciona a rota unicast mais específica na tabela de roteamento unicast que corresponde ao prefixo de destino 10.1.1.1/32. Em uma tabela de roteamento unicast contendo 10,1/16 e 10.1.1/24, esta última é escolhida como a rota unicast para comparar. Considera-se apenas a entrada ativa da rota unicast. Isso segue o conceito de que uma rota de fluxo é válida se anunciada pelo criador da melhor rota unicast.

O segundo critério trata de situações em que um determinado bloco de endereço é alocado para diferentes entidades. Fluxos que se resolvem para uma rota unicast de melhor correspondência que é uma rota agregada só são aceitos se não cobrirem rotas mais específicas que estão sendo roteadas para diferentes sistemas autônomos de next-hop.

Você pode contornar o processo de validação de rotas de fluxo usando mensagens BGP NLRI e usar sua própria política de importação específica. Quando o BGP transporta mensagens NLRI de especificação de fluxo, a no-validate declaração no nível da [edit protocols bgp group group-name family inet flow] hierarquia omite o procedimento de validação da rota de fluxo após os pacotes serem aceitos por uma política. Você pode configurar a política de importação para combinar com atributos de endereço e caminho de destino, como a comunidade, o next-hop e o caminho AS. Você pode especificar a ação a tomar se o pacote corresponde às condições configuradas na rota de fluxo. Para configurar uma ação, inclua a declaração no nível de [edit routing-options flow] hierarquia. O tipo NLRI de especificação de fluxo inclui componentes como prefixo de destino, prefixo de origem, protocolo e portas conforme definido no RFC 5575. A política de importação pode filtrar uma rota de entrada usando atributos de caminho e endereço de destino na especificação de fluxo NLRI. A política de importação não pode filtrar nenhum outro componente no RFC 5575.

A especificação de fluxo define as extensões de protocolo necessárias para atender aos aplicativos mais comuns de filtragem unicast IPv4 e VPN unicast. O mesmo mecanismo pode ser reutilizado e novos critérios de correspondência adicionados para abordar filtragem semelhante para outras famílias de endereços BGP (por exemplo, IPv6 unicast).

Depois que uma rota de fluxo é instalada na inetflow.0 tabela, ela também é adicionada à lista de filtros de firewall no kernel.

Somente nos roteadores, as mensagens NLRI de especificação de fluxo são suportadas em VPNs. A VPN compara o alvo de rota da comunidade estendida no NLRI com a política de importação. Se houver correspondência, a VPN pode começar a usar as rotas de fluxo para filtrar e limitar o tráfego de pacotes. As rotas de fluxo recebidas são instaladas na tabela instance-name.inetflow.0de roteamento de fluxo. As rotas de fluxo também podem ser propagadas por toda a rede VPN e compartilhadas entre VPNs. Para permitir que o BGP multiprotocol (MP-BGP) carregue NLRI de especificação de fluxo para a família de inet-vpn endereços, inclua a flow declaração no nível de [edit protocols bgp group group-name family inet-vpn] hierarquia. As rotas de fluxo de VPN são suportadas apenas para a instância padrão. As rotas de fluxo configuradas para VPNs com família inet-vpn não são validadas automaticamente, portanto, a no-validate declaração não é suportada no nível de [edit protocols bgp group group-name family inet-vpn] hierarquia. Nenhuma validação é necessária se as rotas de fluxo forem configuradas localmente entre dispositivos em um único AS.

Políticas de importação e exportação podem ser aplicadas ao family inet flow NLRI ou family inet-vpn flow ao NLRI, afetando as rotas de fluxo aceitas ou anunciadas, semelhante à forma como as políticas de importação e exportação são aplicadas a outras famílias BGP. A única diferença é que a configuração da política de fluxo deve incluir a from rib inetflow.0 declaração. Esta declaração faz com que a política seja aplicada às rotas de fluxo. Uma exceção a esta regra ocorre se a política tiver apenas a then reject declaração ou a then accept declaração e nenhuma from declaração. Em seguida, a política afeta todas as rotas, incluindo ip unicast e fluxo ip.

Este exemplo mostra como configurar as seguintes políticas de exportação:

  • Uma política que permite a publicidade de rotas de fluxo especificadas por um filtro de rota. Apenas as rotas de fluxo cobertas pelo bloco 10.13/16 são anunciadas. Essa política não afeta as rotas unicast.

  • Uma política que permite que todas as rotas unicast e de fluxo sejam anunciadas ao vizinho.

  • Uma política que permite que todas as rotas (unicast ou fluxo) sejam anunciadas ao vizinho.

Topologia

Cópia de

Configurando uma rota de fluxo estático

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 os detalhes necessários para combinar com a configuração de sua rede e, em seguida, copie e cole os comandos na CLI no nível de [edit] hierarquia.

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 pela CLI, consulte o uso do editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.

Para configurar as sessões de peer BGP:

  1. Configure as condições de correspondência.

  2. Configure a ação.

  3. (Recomendado) Para o algoritmo de especificação de fluxo, configure a ordem de prazo padrão.

    No algoritmo de pedido de prazo padrão, conforme especificado no draft do RFC de fluxo versão 6, um termo com condições de correspondência menos específicas é sempre avaliado antes de um termo com condições de correspondência mais específicas. Isso faz com que o termo com condições de correspondência mais específicas nunca seja avaliado. A versão 7 do RFC 5575 fez uma revisão para o algoritmo para que as condições de correspondência mais específicas sejam avaliadas antes das condições de correspondência menos específicas. Para compatibilidade reversa, o comportamento padrão não é alterado no Junos OS, embora o algoritmo mais novo faça mais sentido. Para usar o algoritmo mais novo, inclua a term-order standard declaração na configuração. Esta declaração é suportada no Junos OS Release 10.0 e posterior.

Resultados

A partir do modo de configuração, confirme sua configuração entrando no show routing-options comando. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Se você terminar de configurar o dispositivo, entre no commit modo de configuração.

Rotas de fluxo de publicidade especificadas por um filtro de rota

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 os detalhes necessários para combinar com a configuração de sua rede e, em seguida, copie e cole os comandos na CLI no nível de [edit] hierarquia.

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 pela CLI, consulte o uso do editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.

Para configurar as sessões de peer BGP:

  1. Configure o grupo BGP.

  2. Configure a política de fluxo.

  3. Configure o número do sistema autônomo local (AS).

Resultados

A partir do modo de configuração, confirme sua configuração entrando no show protocolse show policy-optionsshow routing-options nos comandos. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Se você terminar de configurar o dispositivo, entre no commit modo de configuração.

Publicidade de todas as rotas unicast e de fluxo

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 os detalhes necessários para combinar com a configuração de sua rede e, em seguida, copie e cole os comandos na CLI no nível de [edit] hierarquia.

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 pela CLI, consulte o uso do editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.

Para configurar as sessões de peer BGP:

  1. Configure o grupo BGP.

  2. Configure a política de fluxo.

  3. Configure o número do sistema autônomo local (AS).

Resultados

A partir do modo de configuração, confirme sua configuração entrando no show protocolse show policy-optionsshow routing-options nos comandos. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Se você terminar de configurar o dispositivo, entre no commit modo de configuração.

Publicidade Sem Unicast ou rotas de fluxo

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 os detalhes necessários para combinar com a configuração de sua rede e, em seguida, copie e cole os comandos na CLI no nível de [edit] hierarquia.

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 pela CLI, consulte o uso do editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.

Para configurar as sessões de peer BGP:

  1. Configure o grupo BGP.

  2. Configure a política de fluxo.

  3. Configure o número do sistema autônomo local (AS).

Resultados

A partir do modo de configuração, confirme sua configuração entrando no show protocolse show policy-optionsshow routing-options nos comandos. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Se você terminar de configurar o dispositivo, entre no commit modo de configuração.

Limitando o número de rotas de fluxo instaladas em uma tabela de roteamento

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 os detalhes necessários para combinar com a configuração de sua rede e, em seguida, copie e cole os comandos na CLI no nível de [edit] hierarquia.

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 pela CLI, consulte o uso do editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.

Nota:

A aplicação de um limite de rota pode resultar em um comportamento imprevisível de protocolo de rota dinâmica. Por exemplo, uma vez que o limite é atingido e as rotas estão sendo rejeitadas, o BGP não necessariamente tenta reinstalar as rotas rejeitadas após o número de rotas cair abaixo do limite. As sessões de BGP podem precisar ser liberadas para resolver esse problema.

Para limitar as rotas de fluxo:

  1. Estabeleça um limite superior para o número de prefixos instalados na inetflow.0 tabela.

  2. Estabeleça um valor limite de 50%, onde quando 500 rotas são instaladas, um aviso é registrado no log do sistema.

Resultados

A partir do modo de configuração, confirme sua configuração entrando no show routing-options comando. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Se você terminar de configurar o dispositivo, entre no commit modo de configuração.

Limitando o número de prefixos recebidos em uma sessão de peering BGP

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 os detalhes necessários para combinar com a configuração de sua rede e, em seguida, copie e cole os comandos na CLI no nível de [edit] hierarquia.

Nota:

Você pode incluir a opção teardown <percentage>, drop-excess <percentage>ou hide-excess<percentage> declaração, uma de cada vez.

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 pela CLI, consulte o uso do editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.

Configurar um limite de prefixo para um vizinho específico fornece controle mais previsível sobre qual peer pode anunciar quantas rotas de fluxo.

Para limitar o número de prefixos:

  1. Estabeleça um limite de 1000 rotas BGP do vizinho 10.12.99.2.

  2. Configure a sessão ou os prefixos vizinhos para executar teardown <percentage>, drop-excess <percentage>ou hide-excess<percentage> a opção de declaração quando a sessão ou os prefixos atingirem seu limite.

    Se você especificar a teardown <percentage> declaração e especificar uma porcentagem, as mensagens são registradas quando o número de prefixos atinge essa porcentagem. Após a sessão ser derrubada, a sessão restabelece em pouco tempo, a menos que você inclua a idle-timeout declaração.

    Se você especificar a drop-excess <percentage> declaração e especificar uma porcentagem, o excesso de rotas é descartado quando o número de prefixos excede essa porcentagem

    Se você especificar a hide-excess <percentage> declaração e especificar uma porcentagem, as rotas em excesso ficam ocultas quando o número de prefixos excede essa porcentagem.

Resultados

A partir do modo de configuração, confirme sua configuração entrando no show protocols comando. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Se você terminar de configurar o dispositivo, entre no commit modo de configuração.

Verificação

Confirme que a configuração está funcionando corretamente.

Verificando o NLRI

Propósito

Veja o NLRI habilitado para o vizinho.

Ação

Do modo operacional, execute o show bgp neighbor 10.12.99.5 comando. inet-flow Procure na saída.

Verificação de rotas

Propósito

Veja as rotas de fluxo. A saída da amostra mostra uma rota de fluxo aprendida com o BGP e uma rota de fluxo configurada estaticamente.

Para rotas de fluxo configuradas localmente (configuradas no nível de [edit routing-options flow] hierarquia), as rotas são instaladas pelo protocolo de fluxo. Portanto, você pode exibir as rotas de fluxo especificando a tabela, como dentro show route table inetflow.0 ou show route table instance-name.inetflow.0, onde instance-name está o nome da instância de roteamento. Ou, você pode exibir todas as rotas de fluxo configuradas localmente em várias instâncias de roteamento executando o show route protocol flow comando.

Se uma rota de fluxo não estiver configurada localmente, mas for recebida do peer BGP do roteador, essa rota de fluxo será instalada na tabela de roteamento pelo BGP. Você pode exibir as rotas de fluxo especificando a tabela ou executando show route protocol bgp, que exibe todas as rotas BGP (fluxo e sem fluxo).

Ação

Do modo operacional, execute o show route table inetflow.0 comando.

Significado

Uma rota de fluxo representa um termo de filtro de firewall. Quando você configura uma rota de fluxo, você especifica as condições de correspondência e as ações. Nos atributos da correspondência, você pode combinar um endereço de origem, um endereço de destino e outras qualificações, como a porta e o protocolo. Para uma única rota de fluxo que contenha várias condições de correspondência, todas as condições de correspondência são encapsuladas no campo de prefixo da rota. Quando você emite o show route comando em uma rota de fluxo, o campo de prefixo da rota é exibido com todas as condições de correspondência. 10.12.44.1,*match destination 10.12.44.1/32 Se o prefixo na saída fosse *,10.12.44.1, isso significaria que a condição da correspondência era match source 10.12.44.1/32. Se as condições correspondentes conterem uma origem e um destino, o asterisco será substituído pelo endereço.

Os números de ordem de prazo indicam a sequência dos termos (rotas de fluxo) sendo avaliados no filtro de firewall. O show route extensive comando exibe as ações para cada termo (rota).

Verificação da validação do fluxo

Propósito

Informações de rota de fluxo de exibição.

Ação

Do modo operacional, execute o show route flow validation detail comando.

Verificação de filtros de firewall

Propósito

Exibir os filtros de firewall instalados no kernel.

Ação

Do modo operacional, execute o show firewall comando.

Verificação do registro do sistema ao exceder o número de rotas de fluxo permitidas

Propósito

Se você configurar um limite no número de rotas de fluxo instaladas, conforme descrito Limitando o número de rotas de fluxo instaladas em uma tabela de roteamento, visualizar a mensagem de registro do sistema quando o limiar for atingido.

Ação

Do modo operacional, execute o show log <message> comando.

Verificação do registro do sistema ao exceder o número de prefixos recebidos em uma sessão de peering BGP

Propósito

Se você configurar um limite no número de rotas de fluxo instaladas, conforme descrito Limitando o número de prefixos recebidos em uma sessão de peering BGP, visualizar a mensagem de registro do sistema quando o limiar for atingido.

Ação

Do modo operacional, execute o show log message comando.

Se você especificar a opção de teradown <percentage> declaração:

Se você especificar a opção de drop-excess <percentage> declaração:

Se você especificar a opção de hide-excess <percentage> declaração:

Example: Configuração do BGP para levar rotas de especificação de fluxo IPv6

Este exemplo mostra como configurar a especificação de fluxo IPv6 para filtragem de tráfego. A especificação de fluxo BGP pode ser usada para automatizar a coordenação entre domínios e domínios das regras de filtragem de tráfego, a fim de mitigar ataques de negação de serviço.

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Dois roteadores da Série MX

  • Junos OS Versão 16.1 ou posterior

Antes de habilitar o BGP a transportar rotas de especificação de fluxo IPv6:

  1. Configure endereços IP nas interfaces do dispositivo.

  2. Configure BGP.

  3. Configure uma política de roteamento que exporta rotas (como rotas estáticas, rotas diretas ou rotas IGP) da tabela de roteamento para o BGP.

Visão geral

A especificação flow fornece proteção contra ataques de negação de serviço e restringe o tráfego ruim que consome a largura de banda e a impede de chegar perto da fonte. Nas versões anteriores do Junos OS, as regras de especificação de fluxo foram propagadas para IPv4 no BGP como informações de alcance da camada de rede. Começando pelo Junos OS Release 16.1, o recurso de especificação de fluxo é suportado na família IPv6 e permite a propagação de regras de especificação de fluxo de tráfego para VPN IPv6 e IPv6.

Topologia

Figura 7 mostra a topologia da amostra. O roteador R1 e o roteador R2 pertencem a diferentes sistemas autônomos. A especificação de fluxo IPv6 está configurada no Roteador R2. Todo o tráfego de entrada é filtrado com base nas condições de especificação de fluxo, e o tráfego é tratado de maneira diferente dependendo da ação especificada. Neste exemplo, todo o tráfego que vai para abcd:11:11:11:10/128 que corresponda às condições de especificação do fluxo é descartado; enquanto que o tráfego destinado a abcd:11:11:11:30/128 e correspondente às condições de especificação de fluxo é aceito.

Figura 7: Configurando BGP para transportar rotas de fluxo IPv6Configurando BGP para transportar rotas de fluxo IPv6

Cópia de

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 sua configuração de rede, copiar e colar os comandos na CLI no nível de [edit] hierarquia e, em seguida, entrar no commit modo de configuração.

Roteador R1

Roteador R2

Configuração do roteador R2

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 pela CLI, consulte o uso do Editor de CLI no modo de configuração no guia de usuário da CLI.

Para configurar o roteador R2:

Nota:

Repita este procedimento para roteador R1 depois de modificar os nomes, endereços e outros parâmetros de interface apropriados.

  1. Configure as interfaces com endereços IPv6.

  2. Configure o endereço de loopback IPv6.

  3. Configure o número de ID e sistema autônomo (AS) do roteador.

  4. Configure uma sessão de peering EBGP entre o roteador R1 e o roteador R2.

  5. Configure uma rota estática e um próximo salto. Assim, uma rota é adicionada à tabela de roteamento para verificar o recurso neste exemplo.

  6. Especifique as condições de especificação do fluxo.

  7. Configure uma discard ação para descartar pacotes que correspondam às condições de correspondência especificadas.

  8. Especifique as condições de especificação do fluxo.

  9. Configure uma accept ação para aceitar pacotes que correspondam às condições de correspondência especificadas

  10. Defina uma política que permite que o BGP aceite rotas estáticas.

Resultados

A partir do modo de configuração, confirme sua configuração entrando nosshow interfaces, show protocolsshow routing-optionse show policy-options comandos. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Verificação

Confirme que a configuração está funcionando corretamente.

Verificando a presença de rotas de especificação de fluxo IPv6 na tabela de fluxo de inet6

Propósito

Exibir as rotas na inet6flow tabela no Roteador R1 e R2 e verificar se a BGP aprendeu as rotas de fluxo.

Ação

Do modo operacional, execute o show route table inet6flow.0 extensive comando no roteador R1.

Do modo operacional, execute o show route table inet6flow.0 extensive comando no roteador R2.

Significado

A presença de rotas abcd:11:11:11:11/128 e abcd::11:11:11:30/128 na tabela confirma que a inet6flow BGP aprendeu as rotas de fluxo.

Verificando as informações do resumo do BGP

Propósito

Verifique se a configuração BGP está correta.

Ação

Do modo operacional, execute o show bgp summary comando no roteador R1 e R2.

Significado

Verifique se a inet6.0 tabela contém o endereço vizinho BGP e uma sessão de peering foi estabelecida com seu vizinho BGP.

Verificação da validação do fluxo

Propósito

Informações de rota de fluxo de exibição.

Ação

Do modo operacional, execute o show route flow validation comando no roteador R1.

Significado

A saída exibe as rotas de fluxo na inet6.0 tabela.

Verificando a especificação de fluxo das rotas IPv6

Propósito

Exibir o número de pacotes que são descartados e aceitos com base nas rotas de especificação de fluxo especificadas.

Ação

Do modo operacional, execute o show firewall filter_flowspec_default_inet6_ comando no roteador R2.

Significado

A saída indica que os pacotes destinados ao abcd:11:11:11:10/128 são descartados e 88826 pacotes foram aceitos para a rota abcd::11:11:11:11:11:30/128.

Configuração da ação de especificação de fluxo BGP redirecione para IP para filtrar tráfego DDoS

A partir do Junos OS Release 18.4R1, especificação de fluxo BGP conforme descrito no draft do draft do BGP Flow-Spec Internet draft-ietf-idr-flowspec-redirect-ip-02.txt, o redirecionamento para o IP Action é suportado. Redirecionar para a ação IP usa a comunidade BGP estendida para fornecer opções de filtragem de tráfego para mitigação de DDoS em redes de provedores de serviços. A especificação de fluxo legado redireciona para IP usa o atributo BGP nexthop. O Junos OS anuncia o redirecionamento para a ação de especificação de fluxo IP usando a comunidade estendida por padrão. Esse recurso é necessário para dar suporte ao encadeamento de serviços no gateway de controle de serviços virtual (vSCG). Redirecionar para a ação IP permite desviar o tráfego de especificação de fluxo correspondente para um endereço globalmente acessível que pode ser conectado a um dispositivo de filtragem que pode filtrar o tráfego DDoS e enviar o tráfego limpo para o dispositivo de saída.

Antes de começar a redirecionar o tráfego para IP para rotas de especificação de fluxo BGP, faça o seguinte:

  1. Configure as interfaces do dispositivo.

  2. Configure o OSPF ou qualquer outro protocolo IGP.

  3. Configure MPLS e LDP.

  4. Configure BGP.

Configure o redirecionamento para o recurso IP usando a comunidade estendida BGP.

  1. Configure o redirecionamento para a ação IP para rotas estáticas de especificação de fluxo IPv4 conforme especificado no draft do draft do BGP Flow-Spec Internet draft-ietf-idr-flowspec-redirect-ip-02.txt, Redirecione para a ação IP .

    O Junos OS anuncia o redirecionamento para a ação de especificação de fluxo IP usando o redirecionamento da comunidade estendida para IP por padrão. O dispositivo de entrada detecta e envia o tráfego DDoS para o endereço IP especificado.

    Por exemplo, redirecione o tráfego DDoS para o endereço IPv4 10.1.1.1.

  2. Configure o redirecionamento para a ação IP para rotas de especificação de fluxo IPv6 estáticas.

    Por exemplo, redirecione o tráfego DDoS para o endereço IPv6 1002:db8::

  3. Defina uma política para filtrar o tráfego de uma comunidade BGP específica.

    Por exemplo, defina uma política p1 para filtrar o tráfego da comunidade BGP redirip.

  4. Defina uma política para definir, adicionar ou excluir uma comunidade BGP e especifique a comunidade estendida.

    Por exemplo, defina uma política p1 para definir, adicionar ou excluir um reidirip da comunidade e uma comunidade estendida para redirecionar o tráfego para o endereço IP 10.1.1.1.

  5. Configure o BGP para usar a tabela VRF.inet.0 para resolver rotas de especificação de fluxo VRF, incluindo declaração no nível de hierarquia.

Configure o redirecionamento da especificação de fluxo legado para o recurso IP usando o atributo nexthop.

Nota:

Você não pode configurar políticas para redirecionar o tráfego para um endereço IP usando a comunidade estendida BGP e o redirecionamento legado para o próximo endereço IP hop juntos.

  1. Configure o redirecionamento da especificação de fluxo legado para IP especificado no draft da Internet draft-ietf-idr-flowspec-redirect-ip-00.txt, BGP Flow-Spec Extended Community for Traffic Redirect to IP Next Hop incluem no nível de hierarquia.

  2. Defina uma política para combinar com o próximo atributo hop.

    Por exemplo, defina uma política p1 para redirecionar o tráfego para o próximo endereço IP hop 10.1.1.1.

  3. Defina uma política para definir, adicionar ou excluir a comunidade BGP usando a especificação de fluxo legado próximo atributo hop redirecionado para a ação ip.

    Por exemplo, defina uma política p1 e defina, adicione ou exclua um redirnh da comunidade BGP para redirecionar o tráfego DDoS para o próximo endereço IP hop 10.1.1.1.

Encaminhamento de tráfego usando especificação BGP Flow DSCP Action

Configure a ação de DSCP (BgP Flow Specification, Especificação de Fluxo BGP) para encaminhar pacotes usando as informações de prioridade de encaminhamento e perda em toda a rede de maneira eficaz.

Benefícios da ação BGP FlowSpec DSCP para encaminhar pacotes

  • Encaminha o tráfego para as filas de COS pretendidas, onde as políticas de COS são aplicadas corretamente ao tráfego.

  • Influencia o comportamento de encaminhamento local (por exemplo, seleção do túnel) com base no valor DSCP provisionado.

  • Ajuda a gerenciar o tráfego em sua rede de maneira eficaz.

Quando um pacote entra em um roteador, o pacote passa pelos recursos (como firewall, COS, etc.) aplicados na interface de entrada. Quando você configura o filtro BGP FlowSpec na interface de entrada, o filtro é aplicado nos pacotes por instância de roteamento com base na ação do DSCP. A ação do DSCP classifica e reescreve os pacotes, juntamente com a mudança de código DSCP através do filtro BGP FlowSpec. Com base nas informações de prioridade de encaminhamento e perda, os pacotes são colocados na fila de encaminhamento correta. Os pacotes viajam por rotas de fluxo apenas se as condições específicas de correspondência forem atendidas. As condições de correspondência podem ser endereço IP de origem e destino, porta de origem e destino, DSCP, número de protocolo etc. As informações de prioridade de encaminhamento e perda são atualizadas pela tabela de mapeamento reverso.

Aqui está uma topologia de uma sessão BGP estabelecida entre o provedor de serviços e as redes de clientes empresariais.

Benefícios da ação BGP FlowSpec DSCP para encaminhar pacotes

Nesta topologia, uma sessão BGP é configurada entre o provedor de serviços e a rede de clientes empresariais para o BGP FlowSpec. O filtro BGP FlowSpec é aplicado em roteadores PE1 e PE2. Os pacotes que entram nesses roteadores são reescritos com base no filtro BGP FlowSpec e na ação DSCP.

Para habilitar o filtro BGP FlowSpec em um dispositivo, você precisa adicionar a declaração de dscp-mapping-classifier configuração no nível [edit forwarding-options family (inet | inet6)] de hierarquia:

A classe amostra a seguir de mapas de configuração de serviço DSCP aponta para a classe de encaminhamento e prioridade de perda:

Tabela de histórico de liberação
Versão
Descrição
20.3R1
A partir do lançamento do cRPD 20.3R1, as rotas de fluxo e as regras de policiamento propagadas pela especificação de fluxo BGP NLRI são baixadas para o kernel Linux por meio da estrutura do Linux Netfilter em ambientes cRPD.
17.2R1
A partir do Junos OS Release 17.2R1, o BGP pode levar mensagens de informações de alcance da camada de rede (NLRI) de especificações de fluxo em roteadores PTX1000 que têm FPCs de terceira geração instalados.
17.1R1
A partir do Junos OS Release 17.1R1, O BGP pode levar informações de alcance da camada de rede (NLRI) de especificação de fluxo em roteadores da Série PTX que têm FPCs de terceira geração (FPC3-PTX-U2 e FPC3-PTX-U3 no PTX5000 e FPC3-SFF-PTX-U0 e FPC3-SFF-PTX-U1 no PTX3000) instalados.
16.1R4
Começando com o Junos OS Release 16.1R4, a faixa de limite de taxa é [0 a 10000000000].
16.1
Começando pelo Junos OS Release 16.1, o suporte ao IPv6 é estendido à especificação de fluxo BGP que permite a propagação de regras de especificação de fluxo de tráfego para pacotes IPv6 e VPN-IPv6.
16.1
Começando pelo Junos OS Release 16.1R1, a especificação de fluxo BGP oferece suporte à ação de filtragem de marcação extended-community de tráfego.
16.1
A partir do Junos OS Release 16.1, você tem a opção de não aplicar o flowspec filtro ao tráfego recebido em interfaces específicas.
15.1
A partir do Junos OS Release 15.1, as mudanças são implementadas para estender o suporte ininterrupto de roteamento ativo (NSR) para famílias existentes de fluxo de inetvpn e fluxo de inetvpn e estender a validação de rotas para fluxo BGP por draft-ietf-idr-bgp-flowspec-oid-01.