Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Multiprotocol BGP

Entender a multiprotocol BGP

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

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

Para habilitar BGP MP-RI para a família de endereços IPv6, inclua a family inet6 declaração:

Somente nos roteadores, para permitir que o MP-BGP transporte de NLRI (Layer 3 Virtual Private Network, Rede privada virtual) NLRI para a família de endereços IPv4, inclua a family inet-vpn declaração:

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

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

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

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

Para ver 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 da hierarquia, todas as sessões de BGP atuais no dispositivo de roteamento serão lançadas e [edit protocols bgp family] reestabelecidas.

Na versão 9.6 do Junos OS e posterior, você pode especificar um valor de loops para uma família de BGP endereços específico.

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

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

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, unicast L3VPN IPv4

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

  • AFI=2, SAFI=1, unicast IPv6

  • AFI=2, SAFI=2, multicast IPv6

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

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

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

  • AFI=1, SAFI=132, RT-Constrain

  • AFI=1, SAFI=133, Flow-spec

  • AFI=1, SAFI=134, Flow-spec

  • 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, identificado como IPv4

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

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

A tabela de roteamento inet.2 deve ser um subconjunto das rotas que você tem no inet.0, uma vez que é pouco provável que você tenha uma rota para uma origem multicast para a qual você não poderia enviar tráfego unicast. A tabela de roteamento inet.2 armazena as rotas unicast usadas para verificações de encaminhamento de caminho reverso multicast e as informações de alcance adicionais aprendidas pelo MP-BGP com as atualizações de multicast do NLRI. Uma tabela de roteamento inet.2 é criada automaticamente quando você configura o MP-BGP (definindo NLRI como 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 BGP peer e registrar mensagens limitadas à taxa quando o número de prefixos injetados exceder 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 instrução:

Para ver uma lista de níveis de hierarquia nos quais você pode incluir essa declaração, consulte a seção resumo de declarações 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 é ultrapassado, uma mensagem de log do sistema é enviada.

Se você incluir a teardown declaração, a sessão será destruída quando o número máximo de prefixos é excedido. Se você especificar uma porcentagem, as mensagens serão registradas quando o número de prefixos exceder essa porcentagem do limite máximo especificado. Após o fim da sessão, ela será restabelecida em pouco tempo (a menos que você inclua a idle-timeout declaração). Se você incluir a declaração, a sessão pode ser mantida em segredo por um tempo especificado idle-timeout ou para sempre. Se você forever especificar, a sessão será restabelecida somente após o emita um clear bgp neighbor comando. Se você incluir a declaração e especificar uma porcentagem, os excessos de rotas serão descartados quando o número de drop-excess <percentage> prefixos exceder o porcentual. Se você incluir a declaração e especificar uma porcentagem, o excesso de rotas será oculto quando o número de hide-excess <percentage> prefixos exceder a porcentagem. Se a porcentagem for modificada, as rotas serão reavaliadas automaticamente.

Nota:

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

Limitar o número de prefixos aceitos em uma sessão BGP peer

Na versão 9.2 do Junos OS e posterior, você pode limitar o número de prefixos que podem ser aceitos em uma sessão BGP peer. Quando esse limite especificado é ultrapassado, uma mensagem de log do sistema é enviada. Você também pode especificar a reinicialização da 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 BGP peer, inclua a accepted-prefix-limit instrução:

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

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

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

Nota:

Quando o roteamento ativo sem parar (NSR) está ativado e ocorre uma comover para uma Mecanismo de Roteamento de backup, BGP peers que estão para baixo são reinicializados automaticamente. Os peers são reinicializados mesmo que idle-timeout forever a instrução seja configurada.

Nota:

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

Configuração de BGP grupos de tabela de roteamento

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

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

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

Resolução de rotas para dispositivos de roteamento PE localizados em outros ASs

Você pode permitir que rotas etiquetadas sejam colocadas na tabela inet.3 de roteamento para a resolução da rota. Essas rotas são então solucionadas para conexões de dispositivo de roteamento de borda do provedor (PE), onde o PE remoto está localizado em outro sistema autônomo (AS). Para um dispositivo de roteamento PE instalar uma rota na instância de roteamento de roteamento e encaminhamento (VRF) de VPN, o próximo hop deve resolver até uma rota armazenada na inet.3 tabela.

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

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

Permitindo rotas etiquetadas e não nomeadas

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

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

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

Exemplo: Configurando rotas de IPv6 BGP transporte IPv4

Este exemplo demonstra como exportar prefixos IPv6 e IPv4 em 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 os seguintes prefixos ao exportar prefixos IPv6 BGP:

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

    Nota:

    Deve haver uma rota ativa para o próximo hop IPv4-mapped IPv6 para exportar prefixos IPv6 BGP.

  • 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. Neste exemplo, a empilhamento duplo é usada.

  • Ao configurar prefixos IPv4-mapped IPv6, use uma máscara que seja maior que 96 bits.

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

Figura 1 mostra a topologia amostral.

Figura 1: Topologia para configuração de rotas BGP IPv6 via transporte IPv4Topologia para configuração de rotas BGP IPv6 via transporte IPv4

Configuração

Configuração rápida CLI

Para configurar rapidamente este exemplo, copie os comandos a seguir, confie-os em um arquivo de texto, remova quaisquer quebras de linha, altere quaisquer detalhes necessários para combinar com a configuração da rede e, em seguida, copie e copie e colar os comandos na CLI no nível da [edit] hierarquia.

Dispositivo R1

Dispositivo R2

Dispositivo R3

Configurando o dispositivo R1

Procedimento passo a passo

O exemplo a seguir requer que você navegar por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar pela CLI, consulte Como usar o Editor de CLI no modo de configuração no Guia de Usuários da CLI do Junos OS.

Para configurar o dispositivo R1:

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

  2. Configurar EBGP.

  3. Permita BGP transporte de rotas unicast iPv4 e IPv6 unicast. .

    As rotas unicast IPv4 são habilitadas por padrão. A configuração é mostrada aqui para ser completa.

  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 show interfaces inserindo os show policy-options comandos , e show protocols . show routing-options Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

Caso você não configure o dispositivo, entre commit no modo de configuração. Repetir a configuração no dispositivo R2 e no dispositivo R3, alterando os nomes da interface e os endereços IP, conforme necessário.

Verificação

Confirmar se a configuração está funcionando corretamente.

Verificação do status do vizinho

Propósito

Certifique-se de BGP ela está habilitada para transportar rotas unicast IPv6.

Ação

Do modo operacional, insira o show bgp neighbor comando.

Significado

As várias ocorrências na saída mostram que a BGP inet6-unicast é habilitada a transportar rotas unicast IPv6.

Verificação da tabela de roteamento

Propósito

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

Ação

Do modo operacional, insira o show route protocol bgp inet6.0 comando.

Roteiros de IPv4 de publicidade sobre BGP visão geral das sessões do IPv6

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

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

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

Nota:

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

O configurado só local-ipv4-address é usado quando BGP anuncia rotas com auto-next hop. Quando o IBGP anuncia rotas aprendidas com colegas de EBGP ou se o refletor de rotas anuncia BGP rotas para seus clientes, BGP não muda a rota no próximo hop, ignora o configurado e usa o local-ipv4-address próximo hop IPv4 original.

Exemplo: Rotas de IPv4 de publicidade sobre sessões BGP IPv6

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

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Três roteadores com capacidade de empilhamento duplo

  • Junos OS Release 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 de dispositivo.

  2. Configure a pilha dupla em todos os dispositivos.

Visão geral

A partir da versão 16.1, o Junos OS permite BGP anunciar a alcance unicast do IPv4 com o próximo hop de IPv4 em uma sessão de BGP IPv6. Nas versões anteriores do Junos OS, a BGP poderia anunciar apenas sessões inet6 unicast, inet6 multicast e inet6 rótulos unicast address families ao longo de sessões de BGP IPv6. Esse recurso permite BGP trocar todas as BGP endereços das famílias em uma sessão IPv6. Você pode permitir BGP anunciar rotas IPv4 com os próximos hops do IPv4 para BGP peers durante a sessão IPv6. O configurado só local-ipv4-address é usado quando BGP anuncia rotas com auto-next hop.

Nota:

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

Topologia

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

Figura 2: Rotas de IPv4 de publicidade sobre sessões BGP IPv6Rotas de IPv4 de publicidade sobre sessões BGP IPv6

Configuração

Configuração rápida CLI

Para configurar rapidamente este exemplo, copie os comandos a seguir, confie-os em um arquivo de texto, remova quaisquer quebras de linha, altere quaisquer detalhes necessários para combinar a configuração da rede, copie e copie e copie os comandos na CLI no nível da hierarquia e, em seguida, entre no modo de [edit]commit configuração.

Roteador R1

Roteador R2

Roteador R3

Configurando o roteador R1

Procedimento passo a passo

O exemplo a seguir requer que você navegar por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar pela CLI, consulte Como usar o Editor de CLI no modo de configuração no Guia do Usuário da CLI.

Para configurar o roteador R1:

Nota:

Repetir esse 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 precise ser anunciada.

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

  5. Configure eBGP nos roteadores de borda externos.

  6. Ative 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 show interfaces inserindo os show protocols comandos , e show routing-options . show policy-options Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

Caso você não configure o dispositivo, compromete a configuração.

Verificação

Confirmar se a configuração está funcionando corretamente.

Verificar se a sessão BGP final está

Propósito

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

Ação

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

Significado

A BGP está em funcionamento, e BGP peering está estabelecido.

Verificar se o endereço IPv4 está sendo anunciado

Propósito

Verificar 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 do IPv4 está sendo anunciada ao roteador BGP vizinho R2.

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

Propósito

Verificar se o roteador R2 recebe o endereço IPv4 que o roteador R1 anuncia ao BGP vizinho por IPv6.

Ação
Significado

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

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

Em uma rede que transporta principalmente tráfego IPv6, é necessário rotear rotas IPv4 quando necessário. Por exemplo, uma rede Provedor de serviços internet que tenha uma rede somente IPv6, mas que tenha clientes que ainda roteam o tráfego IPv4. Nesse caso, é necessário atender a esses clientes e encaminhá-los por uma rede IPv6. Como descrito no RFC 5549, as informações de alcance do IPv Camada de Rede 4 de publicidade com um tráfego IPv6 Next Hop IPv4 são tuneladas desde dispositivos de equipamentos locais do cliente (CPE) até gateways IPv4-over-IPv6. Esses gateways são anunciados para dispositivos CPE por meio de quaisquer endereçoscast. Os dispositivos de gateway criam túneis dinâmicos IPv4-over-IPv6 para dispositivos CPE remotos e anunciam rotas agregadas IPv4 para orientar o tráfego.

Nota:

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

Os refletores de rotear (RRs) com uma interface programável são conectados por meio do IBGP aos roteadores de gateway e às rotas de host com o 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 dinâmicos IPv4-over-IPv6 para a borda remota do provedor de clientes. O roteador de gateway também anuncia as rotas agregadas do IPv4 para orientar o tráfego. Em seguida, o RR anuncia as rotas de origem do túnel para o ISP. Quando o RR remove a rota do túnel, BGP também retira a rota que faz com que o túnel seja derrubado e o CPE seja inalcançável. O roteador de gateway também retira as rotas agregadas do IPv4 e as rotas de origem do túnel IPv6 quando todas as rotas agregadas do colaborador são removidas. O roteador de gateway envia a rota para fora quando a placa de Mecanismo de Encaminhamento de Pacotes de linha anchor cai, de forma que ele redireciona 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:

BGP Next Hop Encoding

BGP é estendido com o recurso de codificação hop seguinte que é usado para enviar rotas IPv4 com os próximos hops do IPv6. Se esse recurso não estiver disponível no peer remoto, BGP grupos os peers com base nesse recurso de codificação e remove a família BGP sem a capacidade de codificação da lista de informações de alcance da camada de rede negociada (NLRI). O Junos OS permite apenas uma tabela de resolução, como inet.0. Para permitir que o IPv4 BGP rotas com o IPv6, BGP criar 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 de RFC 5549, a publicidade IPv4 Camada de Rede Informações de alcance com um IPv6 Next Hop uma nova comunidade de encapsulamento especificada em RFC 5512, o Identificador de Família de Endereços (SAFI) do encapsulamento de BGP e o atributo BGP Tunnel Encapsulation são introduzidos para determinar a família de endereços do endereço do próximo endereço hop. A comunidade de encapsulamento indica o tipo de túnel que o nó de ingresso precisa criar. Quando BGP recebe rotas IPv4 com o próximo endereço de hop IPv6 e a comunidade de encapsulamento V4oV6, BGP cria túneis dinâmicos IPv4-over-IPv6. Quando BGP recebe rotas sem a comunidade de encapsulamento, BGP as rotas são solucionadas sem criar o túnel V4oV6.

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

Localização de túnel

A infraestrutura de túnel dinâmico é aprimorada com localização de túnel para dar suporte a um número maior de túneis. É necessário que a localização de túneis forneça resiliência para tratar o tráfego quando a ancoragem falha. Um ou mais chassis refanciem um ao outro e deixe o processo de protocolo de roteamento (rpd) desviar o tráfego do ponto de falha até o chassi de backup. O chassi anuncia apenas esses prefixos agregados em vez de endereços de loopback individuais na rede.

Tratamento de túneis

Os túneis IPv4 sobre IPv6 usam a infraestrutura de túnel dinâmico junto com ancoragem de túnel para dar suporte à escala de chassi necessária. O estado do túnel é localizado em uma Mecanismo de Encaminhamento de Pacotes e os outros Mecanismos de Encaminhamento de Pacotes orientam o tráfego até a ancoragem do túnel.

Ingresso no túnel

O encapsulamento de entrada ou túnel do túnel encaminha o tráfego de rede em direção ao local do cliente. Quando o estado do túnel está presente na 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 por 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 header IPv6.

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

  2. Usa balanceamento de carga de tráfego baseado em hash em headers de pacotes internos.

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

Saída do túnel

A saída do túnel encaminha o tráfego do equipamento local 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 está disponível em um PFE remotoTratamento de saída de túnel quando o estado do túnel está disponível em um PFE remoto
  1. Decapsula o pacote IPv4 presente no pacote IPv6.

  2. Realiza verificações anti-spoof para garantir que o par IPv6 e IPv4 se ajuste às informações usadas na configuração do túnel.

  3. Olha o endereço de destino IPv4 do header IPv4 do pacote descapsulado e encaminha o pacote para o endereço IPv4 especificado.

Balanceamento de carga do túnel e ancoragem Mecanismo de Encaminhamento de Pacotes tratamento de falhas

A Mecanismo de Encaminhamento de Pacotes falha precisa ser tratada prontamente para evitar a filtragem de rota nula do tráfego de túnel ancorado no Mecanismo de Encaminhamento de Pacotes. A localização de túneis envolve o uso de BGP anúncios para reparar a falha globalmente. O tráfego do túnel é desviado do ponto de falha para outros chassis 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 de discriminador de saída (MED) para cada um dos conjuntos de prefixo para que apenas o tráfego de um quarto dos túneis seja atravessado por cada chassi. O tráfego de CPE também é tratado de maneira semelhante, configurando o mesmo conjunto de endereçoscast em cada chassi e dirigindo apenas um quarto do tráfego em direção a cada chassi.

Anchor Mecanismo de Encaminhamento de Pacotes é a única entidade que faz todo o processamento por um túnel. A seleção Mecanismo de Encaminhamento de Pacotes anchor é por meio do provisionamento estático e vinculado às Mecanismo de Encaminhamento de Pacotes físicas. Quando um dos Mecanismos de Encaminhamento de Pacotes é derrubado, o daemon marca todos os Mecanismos de Encaminhamento de Pacotes na placa de linha e comunica essas informações ao processo de roteamento do protocolo de roteamento do protocolo do protocolo de roteamento e outros daemons. O processo de protocolo de roteamento envia BGP para os prefixos ancorados no Mecanismo de Encaminhamento de Pacotes e nos endereços IPv6 atribuídos ao Mecanismo de Encaminhamento de Pacotes que estão em baixo. Esses anúncios recaminham o tráfego para outros chassis de backup. Quando a falha Mecanismo de Encaminhamento de Pacotes está novamente, o chassi marca a Mecanismo de Encaminhamento de Pacotes e atualiza o processo up de protocolo de roteamento. O processo de protocolo de roteamento aciona BGP atualizações a seus colegas, que os túneis ancorados à Mecanismo de Encaminhamento de Pacotes específicas agora estão disponíveis para tráfego de roteamento. Esse processo pode levar minutos para a configuração de túnel de grande escala. Portanto, o mecanismo é integrado ao sistema para garantir perda de tráfego mínima ao mesmo tempo em que o tráfego volta Ack ao chassi original.

Estatísticas de fluxo de loopback de túnel

A infraestrutura de túnel dinâmico usa fluxos de loopback Mecanismo de Encaminhamento de Pacotes para looping do pacote após o encapsulamento. Como a largura de banda deste fluxo de loopback é limitada, é necessário monitorar o desempenho de streams de loopback de túnel.

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

Configurando BGP para redistribuir rotas de IPv4 com endereços IPv6 de next-hop

A partir da versão 17.3R1 Release, os dispositivos Junos OS podem encaminhamento do tráfego IPv4 por uma rede somente IPv6, que geralmente não consegue encaminhamento do tráfego IPv4. Como descrito na 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 quaisquer endereçoscast. Os dispositivos de gateway criam túneis dinâmicos IPv4-over-IPv6 para equipamentos locais remotos do cliente e anunciam rotas agregadas IPv4 para orientar 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 por meio do IBGP a roteadores de gateway, que anunciam os endereços IPv4 das rotas de host com endereços IPv6 como o próximo salto.

Nota:

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

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

  1. Configure as interfaces de dispositivo.

  2. Configure OSPF ou qualquer outro protocolo IGP de segurança.

  3. Configure MPLS e LDP.

  4. Configure BGP.

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

  1. Configure a opção de codificação de next-hop estendida para BGP grupos com peers IPv6 para rotear famílias de endereçoS IPv4 em uma sessão IPv6.
  2. Configure túneis IPv4-over-IPv6 dinâmicos e defina seus atributos para encaminhamento do tráfego IPv4 por 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 do atributo do túnel dinâmico configurado a uma lista de prefixos ou a um filtro de roteamento.

    Por exemplo, defina dynamic_tunnel_policy política para associar os atributos do túnel dinâmico first_tunnel apenas ao tráfego em direção a uma rota específica 2.2.2.2/32.

  5. Exporte a política definida.

    Por exemplo, exporte a política de dynamic_tunnel_policy configurada.

Ativação da sinalização de VPN e VPLS de Camada 2

Você pode permitir que BGP transporte de mensagens NLRI de VPN e VPLS de Camada 2.

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

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

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

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

Quando você configura 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á destruída quando o número máximo de prefixos é atingido. Se você especificar uma porcentagem, as mensagens serão registradas quando o número de prefixos atingir essa porcentagem. Após o fim da sessão, ela será restabelecida em pouco tempo. Inclua a declaração para manter a sessão em baixo por idle-timeout um tempo especificado ou para sempre. Se você forever especificar, a sessão será restabelecida somente após o uso do clear bgp neighbor comando. Se você incluir a declaração e especificar uma porcentagem, os excessos de rotas serão descartados quando o número de drop-excess <percentage> prefixos exceder a porcentagem. Se você incluir a declaração e especificar uma porcentagem, o excesso de rotas será oculto quando o número de hide-excess <percentage> prefixos exceder a porcentagem. Se a porcentagem for modificada, as rotas serão reavaliadas automaticamente.

Compreender BGP rotas de fluxo para filtragem de tráfego

Uma rota de fluxo é uma agregação de condições de combinação para pacotes IP. As rotas de fluxo são propagadas pela rede usando mensagens de alcance da camada de rede (NLRI) da especificação de fluxo e instaladas na tabela de roteamento de instance-name.inetflow.0 fluxo. Os pacotes só podem viajar pelas rotas de fluxo se determinadas condições de combinação são atendidas.

Rotas de fluxo e filtros de firewall são semelhantes, na medida em que filtram pacotes com base em seus componentes e realizam uma ação nos pacotes que cumprem. As rotas de fluxo fornecem recursos de filtragem de tráfego e limitação de taxa, bem 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 por BGP por meio de mensagens NLRI de especificação de fluxo. Você deve permitir BGP a propagação desses NLRIs.

A partir da versão 15.1 do Junos OS, as mudanças são implementadas para estender o suporte ao roteamento ativo sem escala (NSR) para as famílias existentes de inet-flow e inetvpn-flow e estender a validação da rota para BGP flowspec por draft-ietf-idr-bgp-flowspec-oid-01. Duas novas declarações são introduzidas como parte desse aprimoramento. Consulte enforce-first-as eno-install.

Nota:

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

A partir da versão 16.1R1 Junos OS, BGP de fluxo aceita a ação de extended-community filtragem da marcação de tráfego. Para o tráfego IPv4, o Junos OS modifica os bits de ponto de código DiffServ (DSCP) de um pacote IPv4 em trânsito até o valor correspondente da comunidade estendida. Para pacotes IPv6, o Junos OS modifica os primeiros seis bits do campo do pacote IPv6 de transmissão ao valor correspondente traffic class da comunidade estendida.

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

Condições de combinação para rotas de fluxo

Você especifica condições que o pacote deve combinar antes que a ação na then instrução seja realizada para uma rota de fluxo. Todas as condições da from declaração devem combinar com as medidas a serem tomadas. A ordem na qual você especifica condições de combinação não é importante, porque um pacote deve atender a todas as condições de um prazo para que um match ocorra.

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

Tabela 1 descreve as condições de combinação da rota de fluxo.

Tabela 1: Condições de combinação da rota de fluxo

Condição de combinação

Descrição

destination prefix prefix-offset number

campo de endereço de destino IP.

Você pode usar o campo opcional, disponível apenas em dispositivos Junos com MPCs aprimorados configurados para o modo, para especificar o número de bits que devem ser ignorados antes do Junos OS começar a combinar um prefix-offsetenhanced-ip prefixo IPv6.

destination-port number

Campo de porta de destino do TCP ou do datagrama do usuário (UDP). Não é possível especificar as port condições e destination-port as combinações no mesmo termo.

No lugar do valor numérico, você pode especificar um dos seguintes sinônimos de texto (os números de porta também estão indicados): afs(1483), bgp (179), biff (512), bootpc (68), bootps (67), cmd (514), cvspserver (2401), dhcp (67), domain (53), eklogin (2105), ekshell (2106), exec (512), finger (79), ftp (21), ftp-datahttp (20), (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), (138), (138), (513), (434), (435), (639), netbios-dgm (138), (138) netbios-nsnetbios-ssn 137), (139), nfsd (2049), nntp (119), ntalk (518), ntp (123), pop3 (110), pptp (1723), printer (515), radacctradius (1813), (1812), rip (520), rkinit (2108), smtp (25), snmp (161), snmptrap (162), snpp (444), socks (1080), ssh (22), sunrpc (111), syslog (514), tacacs-ds (65), talk (517), telnet (23), tftp (69), timedwho (525), (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 tipo de serviço (ToS) no identificador de IP. Os seis bits mais significativos deste byte formam o DSCP.

Você pode especificar DSCP na forma hexadecimal ou decimal.

flow-label numeric-expression

Combinar o valor do rótulo de fluxo. O valor deste campo vai de 0 a 1048575.

Essa condição de combinação é compatível apenas em dispositivos Junos com MPCs aprimorados que estão configurados para enhanced-ip o modo. Essa condição de combinação não é suportada para IPv4.

fragment type

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

  • dont-fragment

    Nota:

    Essa opção não é suportada para IPv6.

  • first-fragment

  • is-fragment

  • last-fragment

  • not-a-fragment

Essa condição de combinação é compatível 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 icmp-type associado, você deve icmp-type especificar 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 relacionados). As palavras-chave são agrupadas pelo tipo ICMP com o qual estão associadas:

  • problema nos parâmetros: 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)

  • ultrapassada no tempo: 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-unknownfragmentation-needed (6), (4), host-precedence-violationhost-unreachable (14), host-unreachable-for-TOS (1), network-unreachable (12), (0), network-unreachable-for-TOS (11), port-unreachableprecedence-cutoff-in-effect (3), (15), protocol-unreachable (2), source-host-isolated (8), source-route-failed (5)

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

Campo do tipo pacote ICMP. Normalmente, você especifica essa combinação com a instrução de combinação para protocol 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 relacionados): echo-reply(0), echo-request (8), info-replyinfo-request (16), (15), mask-request (17), mask-reply (18), parameter-problem (12), redirect (5), router-advertisementrouter-solicit (9), (10), source-quenchtime-exceeded (4), (11), timestamp (13), timestamp-reply (14) ou unreachable (3).

packet-length number

Comprimento total dos pacotes IP.

port number

Campo de porta de destino ou origem de TCP ou UDP. Você não pode especificar a port combinação e a condição ou a combinação no mesmo destination-portsource-port termo.

No lugar do valor numérico, você pode especificar um dos sinônimos de texto indicados 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 relacionados): ah, egp(8), esp (50), gre (47), icmp (1), igmpipip (2), (4), ipv6 (41), ospf (89), pim (103), rsvp (46), tcp (6) ou udp  (17).

Essa condição de combinação é compatível com IPv6 apenas em dispositivos Junos com MPCs aprimorados configurados para enhanced-ip o modo.

source prefixprefix-offset number

campo de endereço de origem IP.

Você pode usar o campo opcional, disponível apenas em dispositivos Junos com MPCs aprimorados configurados para o modo, para especificar o número de bits que devem ser ignorados antes do Junos OS começar a combinar um prefix-offsetenhanced-ip prefixo IPv6.

source-port number

Campo de porta de origem TCP ou UDP. Não é possível especificar port as condições e as source-port combinações no mesmo termo.

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

tcp-flag type

formato de cabeador TCP.

Ações para rotas de fluxo

Você pode especificar a ação a ser tomada se o pacote estiver de acordo com as condições configuradas na rota de fluxo. Para configurar uma ação, inclua a then instrução em nível [edit routing-options flow] de hierarquia.

Tabela 2 descreve as ações de roteamento de fluxo.

Tabela 2: Modificadores de ação da 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 de maneira silenciosa, sem enviar uma mensagem do Protocolo de Mensagem de Controle da Internet (ICMP).

community

Substituir todas as comunidades da rota pelas comunidades especificadas.

valor de marca

De definir um valor DSCP para tráfego que seja o mesmo que 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 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). A partir da versão 16.1R4 Junos OS, o intervalo de limite de taxa é [de 0 a 100000000000].

sample

Amostra 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 somente se elas tenham sido validadas usando o procedimento de validação. A Mecanismo de Roteamento faz a validação antes das rotas de instalação na tabela de roteamento de fluxo.

As rotas de fluxo recebidos BGP as informações de alcance da camada de rede (NLRI) são validadas antes que elas sejam instaladas na tabela de roteamento de instâncias primárias do instance.inetflow.0 fluxo. O procedimento de validação está descrito no draft-ietf-idr-flow-spec-09.txt, Divulgação das regras de especificação de fluxo. Você pode burlar o processo de validação de rotas de fluxo usando BGP mensagens NLRI e usar sua própria política de importação específica.

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

Suporte para BGP algoritmo de especificação de fluxo versão 7 e mais tarde

Por padrão, o Junos OS usa o algoritmo de pedidos de termo definido na versão 6 do draft de especificação de fluxo BGP de fluxo. Na Versão 10.0 do Junos OS e posteriormente, você pode configurar o roteador para atender ao algoritmo de pedidos de termo definido pela primeira vez na versão 7 da especificação de fluxo de BGP e suportado por meio de RFC 5575, Divulgaçãode Rotas de Especificação de Fluxo.

práticas práticas práticas:

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

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

Para reverter a utilização do algoritmo de pedidos de termo definido na versão 6, inclua a legacy declaração em nível de [edit routing-options flow term-order] hierarquia.

Nota:

O pedido de termo configurado só tem importância local. Ou seja, o termo ordem não se propaga com rotas de fluxo enviadas para os peers de BGP remotos, cujo pedido de termo é totalmente determinado por sua própria configuração de ordem de termo. Portanto, você deve ter cuidado ao configurar a ação dependente de pedido quando não tiver conhecimento da configuração de ordem de next term termo dos peers 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 next term onde é especificado como uma ação, mas sem quaisquer condições de combinação configuradas não é suportado.

A partir da Versão 16.1 do Junos OS, você tem a opção de não aplicar o filtro ao tráfego recebido flowspec em interfaces específicas. Um novo termo é adicionado no início do filtro que aceita flowspec 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 filtro de ser aplicado ao tráfego recebido em interfaces específicas, primeiro você deve configurar uma em flowspec tais interfaces, incluindo a instrução do grupo do filtro da família no nível da hierarquia e, em seguida, anexar o filtro ao grupo de interface incluindo a instrução no nível da group-idinetgroup-id[edit interfaces]flowspecflow interface-group group-id exclude[edit routing-options] hierarquia. Você pode configurar apenas uma por group-id instância de roteamento com a set routing-options flow interface-group group-id declaração.

Exemplo: Permitindo BGP transporte de rotas de especificação de fluxo

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

Requisitos

Antes de começar:

  • Configure as interfaces de dispositivo.

  • Configure um protocolo de gateway interior (IGP).

  • Configure BGP.

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

Visão geral

Propagar informações de filtro de firewall como parte BGP permite que você propaga filtros de firewall contra ataques negação de serviço (DOS) de maneira dinâmica em sistemas autônomos. As rotas de fluxo são encapsuladas na NLRI da especificação de fluxo e propagadas por uma rede ou redes privadas virtuais (VPNs), compartilhando informações semelhantes a filtro. As rotas de fluxo são uma agregação de condições de combinação 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 instâncias 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 à família ou à inet flow família NLRI, afetando as rotas de fluxo aceitas ou anunciadas, semelhantes à maneira como as políticas de importação e exportação são aplicadas a outras famílias BGP inet-vpn flow familiares. A única diferença é que a configuração da política de fluxo deve incluir a partir da rib inetflow.0 instrução. Essa declaração faz com que a política seja aplicada às rotas de fluxo. Uma exceção a essa regra ocorre se a política tiver apenas then reject a ou a declaração e nenhuma then acceptfrom declaração. Em seguida, a política afeta todas as rotas, incluindo fluxo de IP unicast e IP.

Os filtros de roteamento de fluxo são configurados inicialmente em um roteador estaticamente, com um conjunto de critérios de correspondência seguidos pelas ações a serem tomadas. Depois, além de , (ou ) estiver configurado entre esse BGP ativado e family inet unicastfamily inet flow seus family inet-vpn flow peers.

Por padrão, rotas de fluxo configuradas estáticamente (filtros de firewall) são anunciadas para outros BGP ativados por BGP que suportam family inet flow o family inet-vpn flow NLRI ou o NLRI.

O dispositivo BGP de recebimento realiza um processo de validação antes de instalar o filtro de firewall na tabela de roteamento de instance-name.inetflow.0 fluxo. O procedimento de validação está descrito na RFC 5575, Disseminação das Regras de Especificação de Fluxo.

O dispositivo BGP de recebimento aceita uma rota de fluxo se passar os seguintes critérios:

  • O originador de uma rota de fluxo combina com o originador da melhor rota unicast de combinação para o endereço de destino que está integrado na rota.

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

O primeiro critério garante que o filtro seja anunciado pelo next-hop usado pelo encaminhamento unicast para o endereço de destino integrado na rota de fluxo. Por exemplo, se uma rota de fluxo for dada como 10.1.1.1, proto=6, porta=80, o dispositivo habilitado para recebimento BGP escolhe 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 a ser comparada. Apenas a entrada da rota unicast ativa é considerada. Isso segue o conceito de que uma rota de fluxo é válida se anunciada pelo originador da melhor rota unicast.

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

Você pode burlar o processo de validação de rotas de fluxo usando BGP mensagens NLRI e usar sua própria política de importação específica. Quando BGP está transportando mensagens NLRI de especificação de fluxo, a instrução em nível de hierarquia omite o processo de validação da rota de fluxo após os pacotes ser aceitos por no-validate[edit protocols bgp group group-name family inet flow] uma política. Você pode configurar a política de importação para atender a atributos de endereço e caminho de destino, como comunidade, next-hop e caminho as. Você pode especificar a ação a ser tomada se o pacote estiver de acordo com as condições configuradas na rota de fluxo. Para configurar uma ação, inclua a instrução em nível [edit routing-options flow] de hierarquia. O tipo de NLRI da 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 extensões de protocolo necessárias para atender às aplicações mais comuns de filtragem de unicast e unicast IPv4 VPN. O mesmo mecanismo pode ser reutilizável e novos critérios de combinação adicionados para abordar filtragem semelhante para outras famílias de BGP endereço (por exemplo, unicast IPv6).

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

Somente nos roteadores, as mensagens NLRI da especificação de fluxo são suportadas em VPNs. A VPN compara a comunidade estendida de destino da rota no NLRI à política de importação. Se houver uma combinação, a VPN pode começar a usar as rotas de fluxo para filtrar e limitar o tráfego de pacotes. As rotas de fluxo recebidos são instaladas na tabela de roteamento de instance-name.inetflow.0 fluxo. As rotas de fluxo também podem ser propagadas por uma rede VPN e compartilhadas entre VPNs. Para permitir que BGP multiprotocol (MP-BGP) transporte NLRI de especificação de fluxo para a família inet-vpn de endereços, inclua a instrução no nível flow[edit protocols bgp group group-name family inet-vpn] da 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 não são validadas automaticamente, portanto, a instrução não é suportada inet-vpnno-validate em nível de [edit protocols bgp group group-name family inet-vpn] hierarquia. Nenhuma validação é necessária se as rotas de fluxo estão configuradas localmente entre dispositivos em um único AS.

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

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

  • Uma política que permite o anúncio de rotas de fluxo especificadas por um filtro de roteamento. Apenas as rotas de fluxo abrangidas pelo bloco de 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 desaprova todas as rotas (unicast ou fluxo) a ser anunciada ao vizinho.

Topologia

Configuração

Configuração de uma rota de fluxo estático

Configuração rápida CLI

Para configurar rapidamente este exemplo, copie os comandos a seguir, confie-os em um arquivo de texto, remova quaisquer quebras de linha, altere quaisquer detalhes necessários para combinar com a configuração da rede e, em seguida, copie e copie e colar os comandos na CLI no nível da [edit] hierarquia.

Procedimento passo a passo

O exemplo a seguir requer que você navegar por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar pela CLI, consulte Como usar o Editor de CLI no modo de configuração no Guia de Usuários da CLI do Junos OS.

Para configurar as sessões BGP peer:

  1. Configure as condições da combinação.

  2. Configure a ação.

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

    No algoritmo de pedidos de termo padrão, como especificado no draft RFC flowspec 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 da RFC 5575 fez uma revisão ao 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. Essa declaração é suportada na versão 10.0 do Junos OS e posterior.

Resultados

A partir do modo de configuração, confirme sua configuração ao entrar no show routing-options comando. Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

Caso você não configure o dispositivo, entre commit no modo de configuração.

Rotas de fluxo de publicidade especificadas por um filtro de rota

Configuração rápida CLI

Para configurar rapidamente este exemplo, copie os comandos a seguir, confie-os em um arquivo de texto, remova quaisquer quebras de linha, altere quaisquer detalhes necessários para combinar com a configuração da rede e, em seguida, copie e copie e colar os comandos na CLI no nível da [edit] hierarquia.

Procedimento passo a passo

O exemplo a seguir requer que você navegar por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar pela CLI, consulte Como usar o Editor de CLI no modo de configuração no Guia de Usuários da CLI do Junos OS.

Para configurar as sessões BGP peer:

  1. Configure o grupo BGP de dados.

  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 show protocols inserindo os show policy-options comandos , e . show routing-options Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

Caso você não configure o dispositivo, entre commit no modo de configuração.

Publicidade de todas as rotas unicast e flow

Configuração rápida CLI

Para configurar rapidamente este exemplo, copie os comandos a seguir, confie-os em um arquivo de texto, remova quaisquer quebras de linha, altere quaisquer detalhes necessários para combinar com a configuração da rede e, em seguida, copie e copie e colar os comandos na CLI no nível da [edit] hierarquia.

Procedimento passo a passo

O exemplo a seguir requer que você navegar por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar pela CLI, consulte Como usar o Editor de CLI no modo de configuração no Guia de Usuários da CLI do Junos OS.

Para configurar as sessões BGP peer:

  1. Configure o grupo BGP de dados.

  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 show protocols inserindo os show policy-options comandos , e . show routing-options Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

Caso você não configure o dispositivo, entre commit no modo de configuração.

Publicidade sem unicast ou rotas de fluxo

Configuração rápida CLI

Para configurar rapidamente este exemplo, copie os comandos a seguir, confie-os em um arquivo de texto, remova quaisquer quebras de linha, altere quaisquer detalhes necessários para combinar com a configuração da rede e, em seguida, copie e copie e colar os comandos na CLI no nível da [edit] hierarquia.

Procedimento passo a passo

O exemplo a seguir requer que você navegar por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar pela CLI, consulte Como usar o Editor de CLI no modo de configuração no Guia de Usuários da CLI do Junos OS.

Para configurar as sessões BGP peer:

  1. Configure o grupo BGP de dados.

  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 show protocols inserindo os show policy-options comandos , e . show routing-options Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

Caso você não configure o dispositivo, entre commit no modo de configuração.

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

Configuração rápida CLI

Para configurar rapidamente este exemplo, copie os comandos a seguir, confie-os em um arquivo de texto, remova quaisquer quebras de linha, altere quaisquer detalhes necessários para combinar com a configuração da rede e, em seguida, copie e copie e colar os comandos na CLI no nível da [edit] hierarquia.

Procedimento passo a passo

O exemplo a seguir requer que você navegar por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar pela CLI, consulte Como usar o Editor de CLI no modo de configuração no Guia de Usuários da CLI do Junos OS.

Nota:

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

Para limitar as rotas de fluxo:

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

  2. De definir um valor de limiar de 50 por cento, 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 ao entrar no show routing-options comando. Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

Caso você não configure o dispositivo, entre commit no modo de configuração.

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

Configuração rápida CLI

Para configurar rapidamente este exemplo, copie os comandos a seguir, confie-os em um arquivo de texto, remova quaisquer quebras de linha, altere quaisquer detalhes necessários para combinar com a configuração da rede e, em seguida, copie e copie e colar os comandos na CLI no nível da [edit] hierarquia.

Nota:

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

Procedimento passo a passo

O exemplo a seguir requer que você navegar por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar pela CLI, consulte Como usar o Editor de CLI no modo de configuração no Guia de Usuários da CLI do Junos OS.

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

Para limitar o número de prefixos:

  1. Definir um limite de 1.000 BGP rotas do vizinho 10.12.99.2.

  2. Configure a sessão ou os prefixos do vizinho para realizar a opção , ou instrução, quando a sessão ou teardown <percentage>drop-excess <percentage> os hide-excess<percentage> prefixos atingirem o limite.

    Se você especificar a instrução e especificar uma porcentagem, as mensagens serão registradas quando o número de teardown <percentage> prefixos chega a essa porcentagem. Depois que a sessão for enviada, a sessão será reestabelecida em pouco tempo, a menos que você inclua a idle-timeout declaração.

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

    Se você especificar a instrução e especificar uma porcentagem, o excesso de rotas será oculto quando o número de hide-excess <percentage> prefixos exceder essa porcentagem.

Resultados

A partir do modo de configuração, confirme sua configuração ao entrar no show protocols comando. Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

Caso você não configure o dispositivo, entre commit no modo de configuração.

Verificação

Confirmar se a configuração está funcionando corretamente.

Verificação do NLRI

Propósito

Veja a NLRI habilitada para o vizinho.

Ação

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

Verificar rotas

Propósito

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

Para rotas de fluxo configuradas localmente (configuradas em nível de hierarquia), as [edit routing-options flow] rotas são instaladas pelo protocolo de fluxo. Portanto, você pode exibir as rotas de fluxo especificando a tabela, como show route table inetflow.0show route table instance-name.inetflow.0 ou, onde instance-name está o nome da instância do 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 se for recebida pelo peer BGP do roteador, essa rota de fluxo será instalada na tabela de roteamento por BGP. Você pode exibir as rotas de fluxo especificando a tabela ou executando, que exibe todas BGP show route protocol bgp rotas (fluxo e não 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. Ao configurar uma rota de fluxo, você especificará as condições da combinação e as ações. Nos atributos da combinação, você pode combinar um endereço de origem, um endereço de destino e outros qualificadores, como a porta e o protocolo. Para uma única rota de fluxo que contém várias condições de combinação, todas as condições de combinação são encapsuladas no campo de prefixo da rota. Ao emitir o comando em uma rota de fluxo, o campo de prefixo da rota é exibido com todas as condições de correspondência. Significa que a condição de correspondência show route10.12.44.1,* é match destination 10.12.44.1/32 . Se o prefixo na saída *,10.12.44.1 fosse, isso significa que a condição da combinação era match source 10.12.44.1/32 . Se as condições correspondentes contiver uma origem e um destino, o asterisco será substituído pelo endereço.

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

Verificação da validação de fluxo

Propósito

Exibir informações de roteamento de fluxo.

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 que estão 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, como descrito, exibirá a mensagem de log do sistema Limitando o número de rotas de fluxo instaladas em uma tabela de roteamento 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 BGP peering

Propósito

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

Ação

Do modo operacional, execute o show log message comando.

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

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

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

Exemplo: Configuração de BGP para realizar rotas de especificação de fluxo IPv6

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

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Dois roteadores da série MX

  • Junos OS Release 16.1 ou mais tarde

Antes de permitir BGP para realizar 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 IGP rotas) da tabela de roteamento para BGP.

Visão geral

A especificação flow fornece proteção contra negação de serviço ataques e restringe tráfego ruim que consome a largura de banda e a interrompe perto da origem. Nas versões anteriores do Junos OS, as regras de especificação de fluxo eram propagadas para IPv4 BGP como informações de alcance da camada de rede. A partir da versão 16.1 do Junos OS, 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 IPv6 e IPv6 VPN.

Topologia

Figura 7 mostra a topologia amostral. 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 em direção a abcd::11:11:11:10/128 que corresponde às condições de especificação de fluxo é descartado; enquanto o tráfego destinado a abcd::11:11:11:30/128 e que combina as condições de especificação de fluxo é aceito.

Figura 7: Configuração de BGP para realizar rotas de fluxo do IPv6Configuração de BGP para realizar rotas de fluxo do IPv6

Configuração

Configuração rápida CLI

Para configurar rapidamente este exemplo, copie os comandos a seguir, confie-os em um arquivo de texto, remova quaisquer quebras de linha, altere quaisquer detalhes necessários para combinar a configuração da rede, copie e copie e copie os comandos na CLI no nível da hierarquia e, em seguida, entre no modo de [edit]commit configuração.

Roteador R1

Roteador R2

Configurando o roteador R2

Procedimento passo a passo

O exemplo a seguir requer que você navegar por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar pela CLI, consulte Como usar o Editor de CLI no modo de configuração no Guia do Usuário da CLI.

Para configurar o roteador R2:

Nota:

Repetir este procedimento para o roteador R1 após 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 a ID do roteador e o número do sistema autônomo (AS).

  4. Configure uma sessão de peering de 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 sejam de acordo com as condições de combinação especificadas.

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

  9. Configure uma accept ação para aceitar pacotes que sejam de acordo com as condições de combinação especificadas

  10. Defina uma política que permita BGP aceitar rotas estáticas.

Resultados

A partir do modo de configuração, confirme sua configuração show interfaces inserindo os show protocols comandos , e show routing-options . show policy-options Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

Verificação

Confirmar se a configuração está funcionando corretamente.

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

Propósito

Exibir as rotas na tabela no roteador R1 e R2 e verificar se BGP inet6flow 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:10/128 e abcd::11:11:11:30/128 na tabela confirma que a BGP apurou as rotas inet6flow de fluxo.

Verificar informações BGP resumo

Propósito

Verificar se a configuração BGP da rede está correta.

Ação

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

Significado

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

Verificação da validação de fluxo

Propósito

Exibir informações de roteamento de fluxo.

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.

Verificação da especificação de fluxo das rotas do 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 a 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.

Configurando uma ação BGP de especificação de fluxo Redirecionar para IP para filtrar DDoS tráfego

A partir da versão 18.4R1 junos OS, a especificação de fluxo BGP descrita no draft do BGP Flow-Spec Internet-draft-ietf-idr-flowspec-redirect-ip-02.txt, Redirecionamento para AÇÃO IP é suportado. Redirecionar para ação IP usa BGP comunidade estendida para fornecer opções de filtragem de tráfego para DDoS mitigação em redes de provedores de serviços. O redirecionamento da especificação de fluxo legado para IP usa o atributo BGP nexthop. Os anúncios do Junos OS redirecionam para ação de especificação de fluxo IP usando a comunidade estendida por padrão. Esse recurso é necessário para dar suporte à encadeamento de serviços no gateway de controle de serviço virtual (vSCG). Redirecionar para ação IP permite desviar tráfego de especificação de fluxo correspondente para um endereço globalmente alcançá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 tráfego para IP para BGP rotas de especificação de fluxo, faça o seguinte:

  1. Configure as interfaces de dispositivo.

  2. Configure OSPF ou qualquer outro protocolo IGP de segurança.

  3. Configure MPLS e LDP.

  4. Configure BGP.

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

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

    Os anúncios do Junos OS redirecionam para 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, redirecionar o tráfego DDoS para o endereço IPv4 10.1.1.1.

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

    Por exemplo, redirecionar o tráfego DDoS para IPv6 endereço 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 BGP comunidade.

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

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

  5. Configurar BGP para usar a tabela VRF.inet.0 para resolver as rotas de especificação de fluxo de VRF incluem instrução em 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 BGP comunidade estendida e o redirecionamento legado para o endereço IP do próximo 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 Comunidade Estendida Flow-Spec para Redirecionamento de tráfego para IP Next Hop inclui no nível da 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 endereço IP do próximo 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 do próximo atributo hop redirecionamento para ação de IP.

    Por exemplo, defina uma política p1 e definir, adicionar ou excluir uma redirnhe da comunidade BGP para redirecionar o tráfego DDoS para o próximo endereço IP hop 10.1.1.1.

Tabela de histórico de liberação
Versão
Descrição
20.3R1
A partir de cRPD release 20.3R1, rotas de fluxo e regras de policiamento propagadas pela especificação de fluxo BGP NLRI são baixadas para o kernel Linux por meio da estrutura Linux Netfilter em ambientes cRPD de segurança.
16.1R4
A partir da versão 16.1R4 Junos OS, o intervalo de limite de taxa é [de 0 a 100000000000].
16.1
A partir da versão 16.1 do Junos OS, o suporte ao IPv6 é estendido para BGP especificação de fluxo que permite a propagação de regras de especificação de fluxo de tráfego para pacotes IPv6 e VPN-IPv6.
16.1
A partir da versão 16.1R1 Junos OS, BGP de fluxo aceita a ação de extended-community filtragem da marcação de tráfego.
16.1
A partir da Versão 16.1 do Junos OS, você tem a opção de não aplicar o filtro ao tráfego recebido flowspec em interfaces específicas.
15.1
A partir da versão 15.1 do Junos OS, as mudanças são implementadas para estender o suporte ao roteamento ativo sem escala (NSR) para as famílias existentes de inet-flow e inetvpn-flow e estender a validação da rota para BGP flowspec por draft-ietf-idr-bgp-flowspec-oid-01.