Nesta página
Configuração do balanceamento de carga com base em rótulos MPLS
Configurações de roteador para a rede MPLS balanceada com carga
Configuração de balanceamento de carga com base em rótulos MPLS em roteadores da Série ACX
Visão geral de balanceamento de carga de carga encapsulada do MPLS
Configuração de carga útil encapsulada MPLS para balanceamento de carga
Entendendo a filtragem baseada em IP e o espelhamento seletivo de portas do tráfego MPLS
Tráfego MPLS com balanceamento de carga
Configuração do balanceamento de carga com base em rótulos MPLS
O balanceamento de carga ocorre em uma base por pacote para fluxos MPLS em plataformas suportadas. A entropia, ou distribuição aleatória, é essencial para a distribuição uniforme de pacotes para seus próximos saltos. Por padrão, quando o balanceamento de carga é usado para ajudar a distribuir tráfego, o Junos OS emprega um algoritmo de hash para selecionar um endereço de próximo salto para instalar na tabela de encaminhamento. Sempre que o conjunto de próximos saltos para um destino muda, o endereço de próximo salto é reeleito por meio do algoritmo de hash. Você pode configurar como o algoritmo de hash é usado para equilibrar o tráfego em um conjunto de caminhos comuados por rótulos de igual custo (LSPs).
Para garantir entropia para tráfego VPLS e VPWS, o Junos OS pode criar um hash com base em dados do cabeçalho IP e até três rótulos MPLS (os chamados rótulos superiores).
Em alguns casos, à medida que o número de recursos de rede que usam rótulos cresce (como MPLS Fast Reroute e RFC 3107, RSVP e VPN) os três principais rótulos podem se tornar estáticos e, portanto, não ser uma fonte suficiente para entropia. O balanceamento de carga pode se tornar distorcido como resultado, ou a incidência da entrega de pacotes fora de pedido pode aumentar. Para esses casos, os rótulos da parte inferior da pilha de rótulos podem ser usados (veja Tabela 1, abaixo, para obter qualificações). Rótulos superiores e rótulos inferiores não podem ser usados ao mesmo tempo.
As placas de MPC não suportam a configuração de chave de hash regular. Para que a configuração de chave de hash baseada em MPC seja eficaz, você precisa de uma configuração enhanced-hash-key .
O balanceamento de carga é usado para distribuir tráfego uniformemente quando as seguintes condições se aplicam:
Existem vários próximos saltos de igual custo em diferentes interfaces para o mesmo destino.
Há um único salto seguinte em uma interface agregada.
Um LSP tende a equilibrar sua colocação selecionando aleatoriamente um dos próximos saltos de igual custo e usando-o exclusivamente. A seleção aleatória é feita de forma independente em cada roteador de trânsito, o que compara apenas as métricas do Interior Gateway Protocol (IGP). Nenhuma consideração é dada aos níveis de largura de banda ou congestionamento.
Esse recurso se aplica a interfaces agregadas de Ethernet e SONET/SDH agregadas, bem como a vários saltos próximos MPLS de igual custo. Além disso, apenas nos roteadores série T, MX, M120 e M320, você pode configurar o balanceamento de carga para tráfego IPv4 em pseudowires Ethernet de Camada 2. Você também pode configurar o balanceamento de carga para pseudowires Ethernet com base em informações de IP. A opção de incluir informações de IP na chave de hash oferece suporte para conexões entre conexões de circuito Ethernet (CCC).
Para o equilíbrio de carga com base nas informações do rótulo MPLS, configure a family mpls declaração:
[edit forwarding-options hash-key] family mpls { all-labels; bottom-label-1; bottom-label-2; bottom-label-3; label-1; label-2; label-3; no-labels; no-label-1-exp; payload { ether-pseudowire; ip { disable; layer-3-only; port-data { destination-lsb; destination-msb; source-lsb; source-msb; } } } }
Você pode incluir essa declaração nos seguintes níveis de hierarquia:
[edit forwarding-options hash-key]
Tabela 1 fornece informações detalhadas sobre todas as possíveis opções de balanceamento de carga MPLS LSP.
Declaração |
Plataformas suportadas |
Opções de balanceamento de carga LSP MPLS |
|---|---|---|
|
Série MX e Série PTX |
Antes do Junos OS Release 19.1R1, até oito rótulos MPLS foram incluídos na chave de hash para identificar a singularidade de um fluxo no Mecanismo de encaminhamento de pacotes. Nos roteadores da Série PTX, esse valor é definido por padrão. A partir do Junos OS Release 19.1R1, para roteadores da Série MX com interfaces MPC e MIC, até dezesseis rótulos MPLS futuros estão incluídos na chave de hash. |
|
Série MX com DPC (I-Chip). Não é compatível com M10i, M7i e M120. |
Usa o rótulo mais baixo para calcular a chave de hash, por exemplo, se as etiquetas superiores não fornecerem variável suficiente para o nível de entropia necessário. |
|
Série MX com DPC (I-Chip). Não é compatível com M10i, M7i e M120. |
Usa o segundo rótulo de baixo para calcular a chave de hash, por exemplo, se as etiquetas superiores não fornecerem variável suficiente para o nível de entropia necessário. |
|
Série MX com DPC (I-Chip). Não é compatível com M10i, M7i e M120. |
Usa o terceiro rótulo da parte inferior para o cálculo da chave de hash, por exemplo, se as etiquetas superiores não fornecerem variável suficiente para o nível de entropia necessário. |
|
Série M, Série MX, Série T |
Inclua o primeiro rótulo na chave de hash. Use essa opção para pacotes de rótulo único. |
|
Série M, Série MX, Série T |
Inclua o segundo rótulo na chave de hash. Você também deve configurar a opção |
|
Série M, Série MX, Série T |
Inclua o terceiro rótulo na chave de hash. Você também deve configurar a opção |
|
Todos |
Exclui os rótulos MPLS da chave de hash. |
|
Série M, Série MX, Série T |
Exclui a bit EXP do rótulo superior da chave de hash. Você também deve configurar a opção Para VPNs de camada 2, o roteador pode encontrar um problema de reordenamento de pacotes. Quando uma explosão de tráfego empurra a largura de banda do tráfego do cliente para exceder seus limites, o tráfego pode ser afetado no fluxo médio. Os pacotes podem ser reordenados como resultado. Ao excluir a bit EXP da chave de hash, você pode evitar esse problema de reordenamento. |
|
Todos |
Permite configurar quais partes da carga de pacote IP incluem na chave de hash. Para o roteador de transporte de pacotes da Série PTX, esse valor é definido por padrão. |
|
Série PTX |
Exclua a carga de IP da chave de hash. |
|
M120, M320, Série MX, Série T |
Tráfego IPv4 com equilíbrio de carga nos pseudowires Ethernet de Camada 2. |
|
Todos |
Inclua o endereço IPv4 ou IPv6 na chave de hash. Você também deve configurar ou |
|
Todos |
Inclua apenas as informações de IP de Camada 3 na chave de hash. Exclui todos os |
|
Série M, Série MX, Série T |
Inclua as informações de campo de porta de origem e destino. Por padrão, o byte mais significativo e o byte menos significativo dos campos de porta de origem e destino são usados na chave de hash. Para selecionar bytes específicos a serem usados na chave de hash, inclua um ou mais opções |
|
Série M, Série MX, Série T |
Inclua o byte menos significativo da porta de destino na chave de hash. Pode ser combinado com qualquer uma das outras |
|
Série M, Série MX, Série T |
Inclua o byte mais significativo da porta de destino na chave de hash. Pode ser combinado com qualquer uma das outras |
|
Série M, Série MX, Série T |
Inclua o byte menos significativo da porta de origem na chave de hash. Pode ser combinado com qualquer uma das outras |
|
Série M, Série MX, Série T |
Inclua o byte mais significativo da porta de origem na chave de hash. Pode ser combinado com qualquer uma das outras |
Os exemplos a seguir ilustram maneiras pelas quais você pode configurar o balanceamento de carga LSP MPLS:
Incluir o endereço IP, bem como o primeiro rótulo na chave de hash:
Para roteadores da Série M, MX e Série T, configure a
label-1declaração e a opçãoippara apayloaddeclaração no[edit forwarding-options hash-key family mpls]nível hierárquicos:[edit forwarding-options hash-key family mpls] label-1; payload { ip; }Para roteadores de transporte de pacotes da Série PTX, a e
ip payloadasall-labelsopções são configuradas por padrão, portanto, nenhuma configuração é necessária.
(Somente roteadores M320 e Série T) Para incluir o endereço IP, bem como os rótulos de primeiro e segundo na chave de hash, configure a e as
label-1opções e a opçãoippara apayloaddeclaração no[edit forwarding-options hash-key family mpls]nível delabel-2hierarquia:[edit forwarding-options hash-key family mpls] label-1; label-2; payload { ip; }Nota:Você pode incluir essa combinação de declarações apenas em roteadores M320 e Série T. Se você incluí-los em um roteador de borda multisserviço da Série M, apenas o primeiro rótulo MPLS e a carga de IP são usados na chave de hash.
Para os roteadores da Série T, garanta um balanceamento de carga adequado, incluindo o
label-1,label-2elabel-3opções no nível de[edit forwarding-options hash-key family mpls]hierarquia:[edit forwarding-options hash-key family mpls] label-1; label-2; label-3;
(Apenas roteadores série M, MX e Série T) Para VPNs de camada 2, o roteador pode encontrar um problema de reordenamento de pacotes. Quando uma explosão de tráfego empurra a largura de banda do tráfego do cliente para exceder seus limites, o tráfego pode ser afetado no fluxo médio. Os pacotes podem ser reordenados como resultado. Ao excluir a bit EXP da chave de hash, você pode evitar esse problema de reordenamento. Para excluir a bit EXP do primeiro rótulo dos cálculos de hash, inclua a
no-label-1-expdeclaração no nível de[edit forwarding-options hash-key family mpls]hierarquia:[edit forwarding-options hash-key family mpls] label-1; no-label-1-exp; payload { ip; }
Exemplo: Rede MPLS balanceada com carga
Quando você configura vários LSPs RSVP para o mesmo roteador de saída, o LSP com a métrica mais baixa é selecionado e transporta todo o tráfego. Se todos os LSPs tiverem a mesma métrica, um dos LSPs será selecionado aleatoriamente e todo o tráfego será encaminhado por ele. Para distribuir tráfego igualmente em todos os LSPs, você pode configurar o balanceamento de carga na entrada ou roteadores de trânsito, dependendo do tipo de balanceamento de carga configurado.
Figura 1 ilustra uma rede MPLS com quatro LSPs configurados para o mesmo roteador de saída (R0). O balanceamento de carga está configurado no roteador R1de entrada. A rede de exemplo usa o Open Shortest Path First (OSPF) como protocolo de gateway interior (IGP) com área 0.0.0.0de OSPF. Um IGP é necessário para o LSP de caminho mais curto limitado primeiro (CSPF), que é o padrão para o Junos OS. Além disso, a rede de exemplo usa uma política para criar tráfego BGP.
A rede mostrada consiste nos Figura 1 seguintes componentes:
Uma topologia BGP interior de malha completa (IBGP), usando AS 65432
MPLS e RSVP habilitados em todos os roteadores
Uma política de envio estático em roteadores R1 e R0 que permite que uma nova rota seja anunciada na rede
Quatro LSPs unidirecionais entre R1 e R0, e um LSP de direção reversa entre R0 e R1, o que permite tráfego bidirecional
Balanceamento de carga configurado no roteador de entrada R1
A rede mostrada Figura 1 é uma rede bgp full-mesh. Como refletores de rota e confederações não são usados para propagar rotas aprendidas no BGP, cada roteador deve ter uma sessão BGP com todos os outros roteadores em execução BGP.
Configurações de roteador para a rede MPLS balanceada com carga
- Propósito
- Ação
- Saída de amostra 1
- Saída de amostra 2
- Saída de amostra 3
- Saída de amostra 4
- Saída de amostra 5
- Saída de amostra 6
- Significado
Propósito
As configurações neste tópico são para os seis roteadores equilibrados em carga, no exemplo de rede ilustrada em Topologia de rede de balanceamento de carga.
Ação
Para exibir a configuração de um roteador, use o seguinte comando de modo operacional Junos OS CLI:
user@host> show configuration | no-more
Saída de amostra 1
A saída de configuração a seguir é para o roteador R6de borda.
user@R6> show configuration | no-more
[...Output truncated...]
interfaces {
fe-0/1/2 {
unit 0 {
family inet {
address 10.0.16.14/30;
}
family mpls; #MPLS enabled on relevant interfaces
}
}
fe-1/3/0 {
unit 0 {
family inet {
address 10.10.12.1/24;
}
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.70.148/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.6.1/32;
}
}
}
}
routing-options {
static {
[...Output truncated...]
router-id 192.168.6.1; #Manually configured RID
autonomous-system 65432; #Full mesh IBGP
}
}
protocols {
rsvp {
interface fe-0/1/2.0;
interface fxp0.0 {
disable;
}
}
mpls {
interface fe-0/1/2.0;
interface fxp0.0 {
disable;
}
}
bgp {
group internal {
type internal;
local-address 192.168.6.1;
neighbor 192.168.1.1;
neighbor 192.168.2.1;
neighbor 192.168.4.1;
neighbor 192.168.9.1;
neighbor 192.168.0.1;
}
}
ospf { #IGP enabled
traffic-engineering;
area 0.0.0.0 {
interface fe-0/1/2.0;
interface fe-1/3/0.0;
interface lo0.0 {
passive; #Ensures protocols do not run over this interface
}
}
}
}
Saída de amostra 2
A saída de configuração a seguir é para o roteador R1de entrada.
user@R1> show configuration | no-more
[...Output truncated...]
interfaces {
fe-0/1/0 {
unit 0 {
family inet {
address 10.0.12.13/30;
}
family mpls; #MPLS enabled on relevant interfaces
}
}
fe-0/1/2 {
unit 0 {
family inet {
address 10.0.16.13/30;
}
family mpls;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.70.143/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.1.1/32;
}
}
}
}
routing-options {
static {
[...Output truncated...]
route 100.100.1.0/24 reject; #Static route for send-statics policy
}
router-id 192.168.1.1; #Manually configured RID
autonomous-system 65432; #Full mesh IBGP
forwarding-table {
export lbpp; #Routes exported to forwarding table
}
}
protocols {
rsvp {
interface fe-0/1/0.0;
interface fe-0/1/2.0;
interface fxp0.0 {
disable;
}
}
mpls {
label-switched-path lsp 1 { #First LSP
to 192.168.0.1; # Destination of the LSP
install 10.0.90.14/32 active; # The prefix is installed in the
primary via-r4; # inet.0 routing table
}
label-switched-path lsp2 {
to 192.168.0.1;
install 10.0.90.14/32 active;
primary via-r2;
}
label-switched-path lsp3 {
to 192.168.0.1;
install 10.0.90.14/32 active;
primary via-r2;
}
label-switched-path lsp4 {
to 192.168.0.1;
install 10.0.90.14/32 active;
primary via-r4;
}
path via-r2 { #Primary path to spread traffic across interfaces
10.0.29.2 loose;
}
path via-r4 {
10.0.24.2 loose;
}
interface fe-0/1/0.0;
interface fe-0/1/2.0;
interface fxp0.0 {
disable;
}
}
bgp {
export send-statics; #Allows advertising of a new route
group internal {
type internal;
local-address 192.168.1.1;
neighbor 192.168.2.1;
neighbor 192.168.4.1;
neighbor 192.168.9.1;
neighbor 192.168.6.1;
neighbor 192.168.0.1;
}
}
ospf { #IGP enabled
traffic-engineering;
area 0.0.0.0 {
interface fe-0/1/0.0;
interface fe-0/1/2.0;
interface lo0.0 {
passive; #Ensures protocols do not run over this interface
}
}
}
}
policy-options { #Load balancing policy
policy-statement lbpp {
then {
load-balance per-packet;
}
}
policy-statement send-statics { #Static route policy
term statics {
from {
route-filter 100.100.1.0/24 exact;
}
then accept;
}
}
}
Saída de amostra 3
A saída de configuração a seguir é para o roteador R2de trânsito.
user@R2> show configuration | no-more
[...Output truncated...]
interfaces {
so-0/0/1 {
unit 0 {
family inet {
address 10.0.24.1/30;
}
family mpls; #MPLS enabled on relevant interfaces
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.0.29.1/30;
}
family mpls;
}
}
fe-0/1/0 {
unit 0 {
family inet {
address 10.0.12.14/30;
}
family mpls;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.70.144/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.2.1/32;
}
}
}
}
routing-options {
static {
[...Output truncated...]
router-id 192.168.2.1; #Manually configured RID
autonomous-system 65432; #Full mesh IBGP
}
}
protocols {
rsvp {
interface so-0/0/1.0;
interface fe-0/1/0.0;
interface so-0/0/2.0;
interface fxp0.0 {
disable;
}
}
mpls {
interface fe-0/1/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0;
interface fxp0.0 {
disable;
}
}
bgp {
group internal {
type internal;
local-address 192.168.2.1;
neighbor 192.168.1.1;
neighbor 192.168.4.1;
neighbor 192.168.9.1;
neighbor 192.168.6.1;
neighbor 192.168.0.1;
}
}
ospf { #IGP enabled
traffic-engineering;
area 0.0.0.0 {
interface fe-0/1/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0;
interface lo0.0 {
passive; #Ensures protocols do not run over this interface
}
}
}
}
Saída de amostra 4
A saída de configuração a seguir é para o roteador R4de trânsito.
user@R4> show configuration | no-more
[...Output truncated...]
interfaces {
so-0/0/1 {
unit 0 {
family inet {
address 10.0.24.2/30;
}
family mpls; # MPLS enabled on relevant interfaces
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.0.49.1/30;
}
family mpls;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.70.146/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.4.1/32;
}
}
}
}
routing-options {
static {
[...Output truncated...]
router-id 192.168.4.1; #Manually configured RID
autonomous-system 65432; #Full mesh IBGP
}
protocols {
rsvp {
interface so-0/0/1.0;
interface so-0/0/3.0;
interface fxp0.0 {
disable;
}
}
mpls {
interface so-0/0/1.0;
interface so-0/0/3.0;
interface fxp0.0 {
disable;
}
}
bgp {
group internal {
type internal;
local-address 192.168.4.1;
neighbor 192.168.1.1;
neighbor 192.168.2.1;
neighbor 192.168.9.1;
neighbor 192.168.6.1;
neighbor 192.168.0.1;
}
}
ospf { #IGP enabled
traffic-engineering;
area 0.0.0.0 {
interface so-0/0/1.0;
interface so-0/0/3.0;
interface lo0.0 {
passive; #Ensures protocols do not run over this interface
}
}
}
}
Saída de amostra 5
A saída de configuração a seguir é para o roteador R9de trânsito.
user@R9> show configuration | no-more
[...Output truncated...]
interfaces {
so-0/0/2 {
unit 0 {
family inet {
address 10.0.29.2/30;
}
family mpls; #MPLS enabled on relevant interfaces
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.0.49.2/30;
}
family mpls;
}
}
fe-0/1/0 {
unit 0 {
family inet {
address 10.0.90.13/30;
}
family mpls;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.69.206/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.9.1/32;
}
}
}
}
routing-options {
static {
[...Output truncated...]
router-id 192.168.9. 1; #Manually configured RID
autonomous-system 65432; #Full mesh IBGP
}
protocols {
rsvp {
interface so-0/0/2.0;
interface so-0/0/3.0;
interface fe-0/1/0.0;
interface fxp0.0 {
disable;
}
}
mpls {
interface so-0/0/2.0;
interface so-0/0/3.0;
interface fe-0/1/0.0;
interface fxp0.0 {
disable;
}
}
bgp {
group internal {
type internal;
local-address 192.168.9.1;
neighbor 192.168.1.1;
neighbor 192.168.2.1;
neighbor 192.168.4.1;
neighbor 192.168.0.1;
neighbor 192.168.6.1;
}
}
ospf { #IGP enabled
traffic-engineering;
area 0.0.0.0 {
interface so-0/0/2.0;
interface so-0/0/3.0;
interface fe-0/1/0.0;
interface lo0.0 {
passive; #Ensures protocols do not run over this interface
}
}
}
}
Saída de amostra 6
A saída de configuração a seguir é para o roteador R0de saída.
user@R0> show configuration | no-more
[...Output truncated...]
interfaces {
fe-0/1/0 {
unit 0 {
family inet {
address 10.0.90.14/30;
}
family mpls; #MPLS enabled on relevant interfaces
}
}
fe-1/3/0 {
unit 0 {
family inet {
address 10.10.11.1/24;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.69.207/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.1/32;
}
}
}
}
routing-options {
static {
[...Output truncated...]
route 100.100.10.0/24 reject; #Static route for send-statics policy
}
router-id 192.168.0.1; #Manually configured RID
autonomous-system 65432; #Full mesh IBGP
}
protocols {
rsvp {
interface fe-0/1/0.0;
interface fe-1/3/0.0;
interface fxp0.0 {
disable;
}
}
mpls {
label-switched-path r0-r6 {
to 192.168.6.1;
}
interface fe-0/1/0.0;
interface fe-1/3/0.0;
interface fxp0.0 {
disable;
}
}
bgp {
group internal {
type internal;
local-address 192.168.0.1;
export send-statics; #Allows advertising of a new route
neighbor 192.168.9.1;
neighbor 192.168.6.1;
neighbor 192.168.1.1;
neighbor 192.168.2.1;
neighbor 192.168.4.1;
}
}
ospf { #IGP enabled
traffic-engineering;
area 0.0.0.0 {
interface fe-0/1/0.0;
interface fe-1/3/0.0;
interface lo0.0 {
passive; #Ensures protocols do not run over this interface
}
}
}
}
policy-options {
policy-statement send-statics {
term statics {
from {
route-filter 100.100.10.0/24 exact;
}
then accept;
}
}
}
Significado
As saídas de amostra de 1 a 6 mostram as interfaces base, opções de roteamento, protocolos e configurações de opções de políticas para todos os seis roteadores na rede de exemplo ilustrada em Exemplo: Rede MPLS balanceada com carga.
Todos os roteadores da rede têm MPLS, RSVP e BGP habilitados. O OSPF está configurado como IGP, e interfaces relevantes têm informações de IP básicas e suporte a MPLS.
Além disso, todos os roteadores têm o ID (RID) do roteador configurado manualmente no nível de [edit routing-options] hierarquia para evitar problemas RID duplicados. A passive declaração está incluída na configuração do OSPF para garantir que os protocolos não sejam executados na interface de loopback (lo0) e que a interface de loopback (lo0) seja anunciada corretamente em toda a rede.
As saídas de amostra 1, 3, 4 e 5 para R6, R2, R4e R9 mostram a configuração base para roteadores comutos de rótulos de trânsito. A configuração base inclui todas as interfaces habilitadas para MPLS, o RID configurado manualmente e os protocolos relevantes (RSVP, MPLS, BGP e OSPF).
A saída de amostra 2 do roteador R1 de entrada mostra a configuração base mais quatro LSPs (lsp1 configurado lsp4) para R0. Os quatro LSPs estão configurados com diferentes caminhos primários que especificam um salto R4 solto para lsp1 e lsp4, e através R2 para lsp2 e lsp3.
Para criar tráfego, R1 tem uma rota estática (100.100.1.0/24) configurada no nível da [edit routing-options static route] hierarquia. O prefixo está incluído na política de envio estático no nível de [edit policy-options send statics] hierarquia para que as rotas possam se tornar rotas BGP.
Além disso, no roteador R1de entrada, o balanceamento de carga é configurado usando a opção per-packet , e a política é exportada no nível hierárquicos [edit routing-options forwarding-table] .
A saída de amostra 6 do roteador R0 de saída mostra um LSP (r0-r6) usado R6 para criar tráfego bidirecional. O OSPF requer acessibilidade bidirecional de LSP antes de anunciar o LSP no IGP. Embora o LSP seja anunciado no IGP, nenhuma mensagem de olá ou atualizações de roteamento ocorrem sobre o LSP — apenas o tráfego de usuário é enviado pelo LSP. O roteador usa sua cópia local do banco de dados do IGP para verificar a acessibilidade bidirecional.
Além disso, R0 tem uma rota estática (100.100.10.0/24) configurada no nível de [edit routing-options static route] hierarquia. O prefixo está incluído na política de envio estático no nível de [edit policy-options send statics] hierarquia para que as rotas possam se tornar rotas BGP.
Configuração de balanceamento de carga com base em rótulos MPLS em roteadores da Série ACX
Tabela 2 fornece informações detalhadas sobre todas as possíveis opções de balanceamento de carga MPLS LSP.
Os roteadores da Série ACX podem ter um equilíbrio de carga por pacote no MPLS. O balanceamento de carga pode ser executado em informações tanto no cabeçalho IP quanto em até três rótulos MPLS, fornecendo uma distribuição mais uniforme do tráfego MPLS para os próximos saltos. Esse recurso é habilitado em plataformas suportadas por padrão e não requer configuração.
O balanceamento de carga é usado para distribuir tráfego uniformemente quando há um único salto seguinte em uma interface agregada ou um pacote LAG. O balanceamento de carga usando rótulos MPLS é suportado apenas para interfaces LAG e não para links multicaminho de igual custo (ECMP).
Por padrão, quando o balanceamento de carga é usado para ajudar a distribuir tráfego, o Junos OS emprega um algoritmo de hash para selecionar um endereço de próximo salto para instalar na tabela de encaminhamento. Sempre que o conjunto de próximos saltos para um destino muda de alguma forma, o endereço de próximo salto é reeleito por meio do algoritmo de hash. Você pode configurar como o algoritmo de hash é usado para equilibrar o tráfego em interfaces em uma interface Ethernet agregada (ae).
Um LSP tende a balancear a carga de sua colocação selecionando aleatoriamente uma das interfaces em um ae- pacote de interface e usando-a exclusivamente. A seleção aleatória é feita de forma independente em cada roteador de trânsito, o que compara apenas as métricas do Interior Gateway Protocol (IGP). Nenhuma consideração é dada aos níveis de largura de banda ou congestionamento.
Nos roteadores da Série ACX, o balanceamento de carga em caminhos comutados rotulados (LSPs) para serviços de LAN privada virtual (VPLS), circuito L2 e rede privada virtual de Camada2 (L2VPN) não são suportados.
Para o equilíbrio de carga com base nas informações do rótulo MPLS, configure a family mpls declaração:
[edit forwarding-options hash-key] family mpls { all-labels; label-1; label-2; label-3; no-labels; payload { ether-pseudowire; ip { layer-3-only; port-data { destination-lsb; destination-msb; source-lsb; source-msb; } } } }
Você pode incluir essa declaração no nível de [edit forwarding-options hash-key] hierarquia.
Quando você configura o ip de carga (user@host# set forwarding-options hash-key family mpls payload ip), configura e layer-3-onlyport-data é obrigatório.
A funcionalidade de balanceamento de carga, sem configuração adequada de hash-keys, pode resultar em um comportamento imprevisível.
Para o término do túnel VPN/pseudowire da Camada 2, até duas etiquetas são usadas para o destino MAC de hashing e carga e os endereços de origem podem ser selecionados opcionalmente. Esses controles podem ser usados para oferecer suporte ao botão ether-pseudowire em mpls familiares sob a configuração hash-key mostrada acima. No entanto, como ACX2000 e ACX4000 também oferecem suporte a pseudowires TDM, os botões de ether-pseudowire só precisam ser usados quando os pseudowires TDM não estão sendo usados.
Para o término do túnel VPN de Camada 3, até dois rótulos são usados para endereços de origem e destino IP de hasing e carga e portas de origem e destino de Camada 4 podem ser selecionadas opcionalmente. Esses controles podem ser usados para oferecer suporte a botões de dados de porta ip em mpls familiares sob a configuração hash-key mostrada acima. No entanto, como as portas de Camada 4 MSB e LSB não podem ser selecionadas individualmente, um dos botões de destino-lsb ou destino-msb ou um dos botões de origem-lsb ou fonte-msb selecionaria as portas de destino ou origem da Camada 4, respectivamente.
Para caso de LSR, até três rótulos são usados para hashing. Se um BOS é visto ao analisar os três primeiros rótulos, o BCM examina a primeira mordidinha de carga - se a mordidinha for 4, a carga é tratada como IPv4 e se a primeira mordisca for 6, a carga é tratada como IPv6 e, nesses casos, endereços IP de fonte de carga e destino podem ser usados de forma insópida para hashing. Esses controles podem ser usados para oferecer suporte a botões de dados de porta ip em mpls familiares sob configuração hash-key. No entanto, as portas de Camada 4 não podem ser usadas para hashing no caso de LSR, e apenas o botão de camada 3 é aplicável. O BCM não reivindica suporte para hashing em campos além dos três rótulos MPLS. O balanceamento de carga para uma única sessão pseudowire não ocorre no caso do LSR, pois todo o tráfego específico para essa sessão levará o mesmo conjunto de rótulos MPLS.
O balanceamento de carga nas interfaces LSR AE pode ser alcançado para um número maior de sessões MPLS, que é mínimo de 10 sessões. Isso é aplicável para CCC/VPLS/L3VPN. No caso da VPN de Camada 3, o tráfego pode não ser igualmente distribuído pelos links de membros, pois os endereços de camada 3 também são contabilizados (juntamente com os rótulos) para a função de entrada de hash.
Para cenários ler, em caso de ACX5048 e ACX5096, o hashing baseado nos campos de Camada 3 e Camada 4 é possível configurando a opção de carga sob a hierarquia "mpls da família". A hashing no LER não é baseada em Rótulos. Para o serviço de Camada 3, é obrigatório mencionar a carga como "somente camada 3" e especificar "dados de porta" no caso do serviço de Camada 4. Você também pode mencionar a contagem de rótulos enquanto configura as teclas de hash nos roteadores LER.
O comportamento de balanceamento de carga de LSR e LER é aplicável para VPN CCC/VPLS/Camada 3 e outros cenários IP MPLS.
Esse recurso se aplica a interfaces Ethernet agregadas e SONET/SDH agregadas. Além disso, você pode configurar o balanceamento de carga para tráfego IPv4 em pseudowires Ethernet de Camada 2. Você também pode configurar o balanceamento de carga para pseudowires Ethernet com base em informações de IP. A opção de incluir informações de IP na chave de hash oferece suporte para conexões entre conexões de circuito Ethernet (CCC).
|
Declaração |
Opções de balanceamento de carga LSP MPLS |
|---|---|
|
|
Inclua o primeiro rótulo na chave de hash. Use essa opção para pacotes de rótulo único. |
|
|
Inclua o segundo rótulo na chave de hash. Você também deve configurar a opção |
|
|
Inclua o terceiro rótulo na chave de hash. Você também deve configurar a opção |
|
|
Exclui os rótulos MPLS da chave de hash. |
|
|
Permite configurar quais partes da carga de pacote IP incluem na chave de hash. Para o switch de transporte de pacotes da Série PTX, esse valor é definido por padrão. |
|
|
Exclua a carga de IP da chave de hash. |
|
|
Tráfego IPv4 com equilíbrio de carga nos pseudowires Ethernet de Camada 2. |
|
|
Inclua o endereço IPv4 ou IPv6 na chave de hash. Você também deve configurar ou |
|
|
Inclua apenas as informações de IP de Camada 3 na chave de hash. Exclui todos os |
|
|
Inclua as informações de campo de porta de origem e destino. Por padrão, o byte mais significativo e o byte menos significativo dos campos de porta de origem e destino são usados na chave de hash. Para selecionar bytes específicos a serem usados na chave de hash, inclua um ou mais opções |
|
|
Inclua o byte menos significativo da porta de destino na chave de hash. Pode ser combinado com qualquer uma das outras |
|
|
Inclua o byte mais significativo da porta de destino na chave de hash. Pode ser combinado com qualquer uma das outras |
|
|
Inclua o byte menos significativo da porta de origem na chave de hash. Pode ser combinado com qualquer uma das outras |
|
|
Inclua o byte mais significativo da porta de origem na chave de hash. Pode ser combinado com qualquer uma das outras |
Para incluir o endereço IP, bem como o primeiro rótulo na chave de hash, configure a label-1 declaração e a opção ip para a payload declaração no nível de [edit forwarding-options hash-key family mpls] hierarquia:
[edit forwarding-options hash-key family mpls]
label-1;
payload {
ip;
}
Para incluir o endereço IP, bem como os rótulos de primeiro e segundo na chave de hash, configure a e as label-1 opções e a opção ip para a payload declaração no [edit forwarding-options hash-key family mpls] nível de label-2 hierarquia:
[edit forwarding-options hash-key family mpls]
label-1;
label-2;
payload {
ip;
}
Garanta um balanceamento de carga adequado, incluindo o label-1label-2nível de hierarquia e label-3 as opções[edit forwarding-options hash-key family mpls]:
[edit forwarding-options hash-key family mpls] label-1; label-2; label-3;
Visão geral de balanceamento de carga de carga encapsulada do MPLS
Os roteadores podem ter um equilíbrio de carga por pacote no MPLS. O balanceamento de carga pode ser executado nas informações tanto no cabeçalho IP quanto em até três rótulos MPLS, fornecendo uma distribuição mais uniforme do tráfego MPLS para os próximos saltos.
O balanceamento de carga é usado para distribuir tráfego uniformemente quando as seguintes condições se aplicam:
Existem vários próximos saltos de igual custo em diferentes interfaces para o mesmo destino.
Há um único salto seguinte em uma interface agregada.
Por padrão, quando o balanceamento de carga é usado para ajudar a distribuir tráfego, um algoritmo de hash é usado para selecionar um endereço de próximo salto para instalar na tabela de encaminhamento. Sempre que o conjunto de próximos saltos para um destino muda de alguma forma, o endereço de próximo salto é reeleito por meio do algoritmo de hash.
No caso de várias redes de camada de transporte, como ethernet sobre MPLS ou pseudowire Ethernet, o algoritmo de hash precisa olhar além do cabeçalho externo da carga e para os cabeçalhos internos para gerar uma distribuição uniforme. Para determinar o encapsulamento interno, o PFE conta com a presença de determinados códigos ou números em offets de carga fixa; por exemplo, a presença de tipo de carga 0X800 ou a presença do protocolo número 4 para um pacote IPv4. No Junos OS, você pode configurar zero-control-word a opção de indicar o início de um quadro Ethernet em uma carga de ether-pseudowire MPLS. Ao ver essa palavra de controle, que é quatro bytes com um valor numérico de todos os zeros, o gerador de hash assume o início de um quadro Ethernet no final da palavra de controle em um pacote MPLS ether-pseudowire.
Para placas baseadas em chip DPC, configure a opção zero-control-word no nível de [edit forwarding-options hash-key family mpls ether-pseudowire] hierarquia; e para placas MPC, configure a opção zero-control-word no nível de [edit forwarding-options enhanced-hash-key family mpls ether-pseudowire] hierarquia.
Configuração de carga útil encapsulada MPLS para balanceamento de carga
Por padrão, quando o balanceamento de carga é usado para ajudar a distribuir tráfego, um algoritmo de hash é usado para selecionar um endereço de próximo salto para instalar na tabela de encaminhamento. Sempre que o conjunto de próximos saltos para um destino muda de alguma forma, o endereço de próximo salto é reeleito por meio do algoritmo de hash. Configure a opção zero-control-word de indicar o início de um quadro Ethernet em uma carga de ether-pseudowire MPLS. Ao ver essa palavra de controle, quatro bytes com um valor numérico de todos os zeros, o gerador de hash assume o início do quadro Ethernet no final da palavra de controle em um pacote MPLS ether-pseudowire.
Antes de começar a configurar a carga encapsulada de MPLS para balanceamento de carga, configure protocolos de roteamento e sinalização.
Para configurar a carga de pagamento encapsulada mpLS para balanceamento de carga:
zero-control-word de indicar o início de um quadro Ethernet em uma carga de ether-pseudowire MPLS. Para placas baseadas em chip DPC, configure a opção
zero-control-wordno nível de[edit forwarding-options hash-key family mpls ether-pseudowire]hierarquia.[edit forwarding-options hash-key family mpls ether-pseudowire] user@host# set zero-control-word
Para placas MPC, configure a opção
zero-control-wordno nível de[edit forwarding-options enhanced-hash-key family mpls ether-pseudowire]hierarquia.[edit forwarding-options enhanced-hash-key family mpls ether-pseudowire] user@host# set zero-control-word
Visão geral das rotas multicaminho baseadas em políticas
As redes de roteamento por segmentos podem ter vários protocolos de transporte no núcleo. Você pode combinar rotas SR-TE LDP ou RSVP de roteamento por segmentos e rotas IP SR-TE e instalar uma rota multicaminho na base de informações de roteamento (também conhecida como tabela de roteamento). Em seguida, você pode direcionar o tráfego de serviços seletivo usando a rota mutlipath através da configuração de políticas.
- Entendendo rotas multicamadas baseadas em políticas
- Benefícios das rotas multicaminho baseadas em políticas
- Rotas multicaminho baseadas em políticas para resolução de rotas
- Resolução de rota de amostra usando rotas multicamadas baseadas em políticas
- Aprimoramento da política de encaminhamento de classe de serviço (CoS)
- Melhorias no protocolo de correspondência de políticas
- Impacto da configuração da rota multicaminho baseada em políticas no desempenho da rede
Entendendo rotas multicamadas baseadas em políticas
Existem diferentes protocolos de transporte em uma rede, como IGP, IGP rotulado, RSVP, LDP e protocolos de engenharia de tráfego de roteamento por segmentos (SR-TE), que são usados para resolver o tráfego de serviços. No entanto, você não poderia usar uma combinação dos protocolos de transporte para resolver o tráfego de serviços. Com a introdução do recurso multicaminho baseado em políticas, você pode combinar rotas LDP de roteamento por segmentos (SR-TE) ou RSVP e rotas DE IP SR-TE para criar uma rota multicaminho que é instalada na base de informações de roteamento. Você pode resolver rotas de serviço BGP pela rota de mutlipath através da configuração de políticas e direcionar o tráfego de forma diferente para diferentes prefixos.
Uma rota multicaminho combinou próximos saltos de entradas de rota que são usados para balanceamento de carga. Todas as rotas de suporte da entrada de rota multicaminho devem estar na mesma base de informações de roteamento. Quando as rotas de suporte estão sob diferentes bases de informações de roteamento, você pode usar a rib-group declaração de configuração para adicionar entradas de rota a uma base de informações de roteamento específica.
Você pode configurar uma rota multicaminho usando uma política para selecionar a lista de rotas cujos próximos saltos devem ser combinados juntos. Quando você inclui a policy-multipath declaração junto com a policy declaração no nível de [edit routing-options rib routing-table-name] hierarquia, uma rota multicaminho baseada em políticas é criada.
O recurso multicaminho baseado em políticas é suportado para protocolos IP e IPv6, e pode ser configurado sob o nível de [edit routing-instances] hierarquia.
Por exemplo:
[edit routing-options] user@host# set rib inet.3 policy-multipath policy example-policy [edit policy-options] user@host# set policy-statement example-policy from example-conditions user@host# set policy-options policy-statement example-policy then accept
A política configurada é aplicada a cada entrada de rota para um determinado prefixo. A rota multicaminho só é criada quando mais de uma rota (incluindo a rota ativa) passa pela política. Quaisquer comandos de ação configurados na política, como aplicar, são avaliados usando a rota ativa. Para rotas não ativas, a política é aplicada para verificar se as rotas podem participar da rota multicaminho ou não. As rotas multicaminho herdam todos os atributos da rota ativa. Esses atributos podem ser modificados usando a configuração de política multicaminho.
Benefícios das rotas multicaminho baseadas em políticas
-
Oferece flexibilidade para combinar protocolos de rede de núcleo para direcionar o tráfego seletivo.
-
Otimiza o desempenho da rede com multicaminho de igual custo ponderado usando rotas multicaminho.
Rotas multicaminho baseadas em políticas para resolução de rotas
Você pode combinar rotas LDP ou RSVP de roteamento por segmentos (SR-TE) e rotas DE IP SR-TE e instalar uma rota multicaminho na base de informações de roteamento. As rotas multicaminho baseadas em políticas não são entradas ativas na base de informações de roteamento. Quando uma rota multicaminho é gerada pela configuração da política, ela é usada para resolver protocolos próximos hops em vez de rotas ativas. Um próximo salto de rota multicaminho é criado pela fusão de gateways de próximos saltos de cada rota constituinte.
Leve o seguinte em consideração ao configurar rotas multicaminho baseadas em políticas para resolução de rotas:
-
Se a rota de membro de uma rota multicaminho aponta para um próximo salto que não seja o próximo salto do roteador ou um próximo salto indireto com encaminhamento próximo salto para o próximo salto do roteador, tais próximos saltos são ignorados.
-
Se as rotas constituintes apontarem para o próximo salto indireto, então os gateways do próximo salto de encaminhamento serão mesclados e o próximo salto indireto é ignorado.
-
Se o número total de gateways exceder o
maximum-ecmpsuporte no dispositivo, apenas osmaximum-ecmpgateways serão retidos e todos os outros gateways serão ignorados. -
É dada preferência a gateways com pesos mais baixos. Quando uma das rotas de membros tem a unilist de próximo saltos indiretos e cada um dos próximos saltos está apontando para um próximo salto de encaminhamento, pode haver valores de peso tanto no próximo salto indireto quanto no próximo salto. Nesses casos, o valor de peso dos gateways é atualizado para refletir o efeito combinado dos pesos em ambos os níveis.
Resolução de rota de amostra usando rotas multicamadas baseadas em políticas
Tomando como exemplo, vamos supor que existam LSPs projetados por roteamento por segmentos, rotas IS-IS de rótulo e LSPs LDP para um destino 10.1.1.1/32, conforme exibido na saída abaixo:
10.1.1.1/32 *[SPRING-TE/8] 00:00:58, metric 1, metric2 30
> to 10.13.1.2 via ge-0/0/1.1, Push 33333, Push 801005, Push 801006(top)
[L-ISIS/14] 1w0d 00:15:57, metric 10
> to 10.12.1.1 via ge-0/0/0.1
to 10.22.1.1 via ge-0/0/0.2
to 10.23.1.1 via ge-0/0/0.3
to 10.24.1.1 via ge-0/0/0.4
to 10.25.1.1 via ge-0/0/0.5
to 10.13.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
[LDP/19] 1w0d 00:09:27, metric 1
> to 10.12.1.1 via ge-0/0/0.1
to 10.22.1.1 via ge-0/0/0.2
to 10.23.1.1 via ge-0/0/0.3
to 10.24.1.1 via ge-0/0/0.4
to 10.25.1.1 via ge-0/0/0.5
to 10.13.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
Aqui, o LSP de roteamento por segmentos é a entrada de rota ativa para o destino 10.1.1.1, e por padrão, apenas esta rota é usada para resolver quaisquer serviços que resolvam mais de 10.1.1.1.
Quando há um requisito de usar mais de um protocolo para resolver rotas de serviço, você pode conseguir isso configurando o multicaminho de políticas para combinar os protocolos. Por exemplo, se o roteamento por segmentos e os caminhos LDP forem necessários para a resolução do serviço, você deve configurar policy-multipath a combinação do roteamento de segment e rotas LDP para prefixo 10.1.1.1.
Por exemplo:
[edit policy-options] user@host# set rib inet.3 policy-multipath policy example-policy user@host# set policy-statement abc term 1 from protocol spring-te user@host# set policy-statement abc term 1 from protocol ldp user@host# set policy-statement abc term 1 from route-filter 10.1.1.1/32 exact user@host# set policy-statement abc term 1 then accept
Com essa configuração, você cria uma rota multicaminho baseada em políticas para prefixo 10.1.1.1/32 que usa entradas de rota constituintes de roteamento por segmentos e protocolos LDP.
Você pode visualizar a rota multicaminho usando a show route saída de comando da seguinte forma:
10.1.1.1/32 *[SPRING-TE/8] 00:10:28, metric 1, metric2 30
> to 10.13.1.2 via ge-0/0/1.1, Push 33333, Push 801005, Push 801006(top)
[L-ISIS/14] 1w0d 00:25:27, metric 10
> to 10.12.1.1 via ge-0/0/0.1
to 10.22.1.1 via ge-0/0/0.2
to 10.23.1.1 via ge-0/0/0.3
to 10.24.1.1 via ge-0/0/0.4
to 10.25.1.1 via ge-0/0/0.5
to 10.13.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
[LDP/19] 1w0d 00:18:57, metric 1
> to 10.12.1.1 via ge-0/0/0.1
to 10.22.1.1 via ge-0/0/0.2
to 10.23.1.1 via ge-0/0/0.3
to 10.24.1.1 via ge-0/0/0.4
to 10.25.1.1 via ge-0/0/0.5
to 10.13.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
[Multipath/8] 00:03:13, metric 1, metric2 30
> to 10.12.1.1 via ge-0/0/0.1
to 10.22.1.1 via ge-0/0/0.2
to 10.23.1.1 via ge-0/0/0.3
to 10.24.1.1 via ge-0/0/0.4
to 10.25.1.1 via ge-0/0/0.5
to 10.13.1.2 via ge-0/0/1.1, Push 33333, Push 801005, Push 801006(top)
to 10.13.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
Você pode ver a saída de comando que a rota multicaminho combina próximos saltos de roteamento por segmentos e caminhos LDP. A rota multicaminho não está ativa e, por padrão, a preferência e a métrica de rota são as mesmas da rota ativa.
Você pode usar as seguintes combinações para a rota multicaminho baseada em poilcy: No entanto, não podemos criar multicaminho de LDP/L-ISIS, pois a rota ativa não faz parte do multicaminho.
-
LSPs e LSPs LDP projetados por roteamento por segmentos.
-
LSPs projetados por tráfego por segmentos e caminhos IS-IS de rótulos.
-
LSPs projetados por tráfego por segmentos, LSPs LDP e caminhos IS-IS de rótulos.
No entanto, você não pode criar uma rota multicamada de LDP e IS-IS de rótulo, pois a rota ativa não faz parte da rota multicaminho.
Com a mesma configuração, assumindo que existe uma rota estática 1.2.3.4/32 configurada com um próximo salto de protocolo de 10.1.1.1,1, essa rota é resolvida usando a rota multicaminho em ambos os LSPs projetados por roteamento por segmentos e LSPs LDP.
Por exemplo:
10.1.3.4/32 *[Static/5] 00:00:12, metric2 1
to 10.12.1.1 via ge-0/0/0.1
> to 10.22.1.1 via ge-0/0/0.2
to 10.23.1.1 via ge-0/0/0.3
to 10.24.1.1 via ge-0/0/0.4
to 10.25.1.1 via ge-0/0/0.5
to 10.13.1.2 via ge-0/0/1.1, Push 33333, Push 801005, Push 801006(top)
to 10.13.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
Aprimoramento da política de encaminhamento de classe de serviço (CoS)
Para o encaminhamento baseado em classe de serviço, você deve usar a declaração de forwarding-policy next-hop-map configuração.
Antes do Junos OS Release 19.1R1, as condições de correspondência suportadas pelo encaminhamento baseado em classe de serviço incluíam:
-
next-hop— Combine o próximo salto com base na interface de saída ou endereço de próximo salto.
-
lsp-next-hop— Combine com LSPs nomeados usando expressão regular de nome LSP.
-
non-lsp-next-hop— Combine todos os LSPs sem um nome LSP.
Com o recurso de rota multicaminho baseado em políticas, você também pode combinar todos os próximos saltos sem um rótulo para determinados prefixos. Para isso, você deve habilitar a opção non-labelled-next-hop no nível hierárquica [edit class-of-service forwarding-policy next-hop-map map-name forwarding-class forwarding-class-name .
Por exemplo:
[edit]
class-of-service {
forwarding-policy {
next-hop-map abc {
forwarding-class best-effort {
non-labelled-next-hop;
}
}
}
}
Melhorias no protocolo de correspondência de políticas
Antes do Junos OS Release 19.1R1, quando você usou uma política para combinar protocolo usando a from protocol declaração no nível de [edit policy-options policy-statement statement-name] hierarquia, todas as rotas de protocolo (rotuladas e não rotuladas) foram combinadas. Com o recurso de rota multicaminho baseado em políticas, você pode combinar rotas de protocolo rotuladas especificamente.
As opções para combinar protocolos rotulados) são:
-
l-isis— Combinar rotas IS-IS rotuladas. A opção
isiscorresponde às rotas IS-IS, excluindo rotas IS-IS de rótulo. -
l-ospf— Rotas de OSPF em laboratório compatíveis. A opção
ospfcombina com todas as rotas OSPF, incluindo OSPFv2, OSPFv3 e OSPF de rótulo.
Por exemplo:
[edit]
policy-options {
policy-statement abc {
from protocol [ l-ospf l-isis ];
}
}
Impacto da configuração da rota multicaminho baseada em políticas no desempenho da rede
Ao configurar uma rota multicaminho baseada em políticas, uma mudança de rota na base de informações de roteamento resulta na avaliação da política para verificar se uma rota multicaminho precisa ser criada. Como esse recurso exige que as rotas de membros devem estar na mesma base de informações de roteamento, a rib-group declaração é usada para mesclar rotas de diferentes bases de informações de roteamento. Configurar a rib-group declaração no nível do aplicativo aumenta o número de rotas no sistema.
Quando existem várias rotas na base de informações de roteamento, a mudança constante de rotas leva à reavaliação da política multicaminho. Isso pode afetar o desempenho da rede. Recomenda-se configurar o recurso de rota multicaminho baseado em políticas apenas quando necessário.
Entendendo a filtragem baseada em IP e o espelhamento seletivo de portas do tráfego MPLS
Em um pacote MPLS, o cabeçalho IP vem imediatamente após o cabeçalho MPLS. O recurso de filtragem baseada em IP oferece um mecanismo de inspeção profundo, onde um máximo de até oito rótulos MPLS da carga interna pode ser inspecionado para permitir a filtragem do tráfego MPLS com base em parâmetros IP. O tráfego MPLS filtrado também pode ser espelhado em um dispositivo de monitoramento para oferecer serviços baseados em rede na rede MPLS principal.
- Filtragem baseada em IP do tráfego MPLS
- Espelhamento seletivo de portas do tráfego MPLS
- Configurações de amostra
Filtragem baseada em IP do tráfego MPLS
Antes do Junos OS Release 18.4R1, a filtragem com base em parâmetros IP não foi suportada para o filtro da família MPLS. Com a introdução do recurso de filtragem baseada em IP, você pode aplicar filtros de entrada e saída para pacotes IPv4 e IPv6 com marca MPLS com base em parâmetros IP, como endereços de origem e destino, tipo de protocolo de Camada 4 e portas de origem e destino.
O recurso de filtragem baseada em IP permite filtrar pacotes MPLS na entrada de uma interface, onde a filtragem é feita usando condições de correspondência na carga interna do pacote MPLS. O tráfego MPLS seletivo pode então ser espelhado em porta para um dispositivo de monitoramento remoto usando túneis lógicos.
Para oferecer suporte à filtragem baseada em IP, são adicionadas condições adicionais de correspondência que permitem que os pacotes MPLS sejam inspecionados profundamente para analisar a carga interna com cabeçalhos de Camada 3 e Camada 4 antes que os filtros apropriados sejam aplicados.
O recurso de filtragem baseado em IP é suportado apenas para pacotes IPv4 e IPv6 com tag MPLS. Em outras palavras, os filtros MPLS correspondem a parâmetros IP apenas quando a carga de IP vem imediatamente após os rótulos MPLS.
Em outros cenários, onde a carga de pagamento MPLS inclui pseudowires, protocolos que não sejam inet e inet6, ou outros encapsulamentos como VPN de Camada 2 ou VPLS, o recurso de filtragem baseado em IP não é suportado.
As seguintes condições de correspondência são adicionadas para a filtragem baseada em IP do tráfego MPLS:
Endereço fonte IPv4
Endereço de destino IPv4
Endereço fonte IPv6
Endereço de destino IPv6
Protocolo
Porta de origem
Porta de destino
Lista de prefixos IPv4 de origem
Lista de prefixos IPv4 de destino
Lista de prefixo IPv6 de origem
Lista de prefixos IPv6 de destino
As combinações de correspondência a seguir são suportadas para a filtragem baseada em IP do tráfego MPLS:
Condições de correspondência de endereços de origem e destino com listas de prefixo IPv4 e IPv6.
Endereço de porta de origem e destino e tipos de protocolo de condições de correspondência com listas de prefixo IPv4 e IPv6.
Espelhamento seletivo de portas do tráfego MPLS
Espelhamento de porta é a capacidade de espelhar um pacote para um destino configurado, além do processamento e encaminhamento normais dos pacotes. O espelhamento de portas é aplicado como uma ação para um filtro de firewall, que é aplicado na entrada ou saída de qualquer interface. Da mesma forma, o recurso de espelhamento de porta seletiva oferece a capacidade de espelhar o tráfego MPLS, que é filtrado com base em parâmetros IP, para um destino espelhado usando túneis lógicos.
Para permitir o espelhamento seletivo de portas, ações adicionais são configuradas no nível de [edit firewall family mpls filter filter-nameterm term-name then] hierarquia, além das ações existentes counteracceptediscard:
port-mirrorport-mirror-instance
Port Mirroring
A port-mirror ação permite o espelhamento de portas globalmente no dispositivo, que se aplica a todos os Mecanismos de encaminhamento de pacotes (PFEs) e interfaces associadas.
Para o filtro da família MPLS, a ação port-mirror é habilitada para espelhamento global de portas.
Port Mirroring Instance
A port-mirror-instance ação permite que você personalize cada instância com propriedades diferentes para destinos de amostragem de entrada e espelhamento de portas, em vez de precisar usar uma única configuração em todo o sistema para espelhamento de portas.
Você pode configurar apenas duas instâncias de espelhamento de porta por Concentrador PIC Flexível (FPC), incluindo a instance port-mirror-instance-name declaração no nível de [edit forwarding-options port-mirror] hierarquia. Em seguida, você pode associar instâncias de espelhamento de portas individuais a uma FPC, PIC ou (Forwarding Engine Board (FEB), dependendo do hardware do dispositivo.
Para o filtro da família MPLS, a ação port-mirror-instance é habilitada apenas para a instância de espelhamento de porta.
Para ambos port-mirror e port-mirror-instance ações, a interface de saída deve ser habilitada com a família Camada 2 e não mpls familiar (Camada 3) para que o recurso de espelhamento de portas seletivo funcione.
Configurações de amostra
- Configuração de filtragem baseada em IP
- Configuração de espelhamento de porta seletiva
- Configuração de destino espelhada
Configuração de filtragem baseada em IP
[edit firewall family mpls filter mpls-filter]
term ipv4-term {
from {
ip-version {
ipv4 {
source-address {
10.10.10.10/24;
}
destination-address {
20.20.20.20/24;
}
protocol tcp {
source-port 100;
destination-port 200;
}
soure-prefix-list ipv4-source-users;
destination-prefix-list ipv4-destination-users;
}
}
exp 1;
}
then port-mirror;
then accept;
then count;
}
term ipv6-term {
from {
ip-version {
ipv6 {
source-address {
2000::1/128;
}
destination-address {
3000::1/128;
}
protocol tcp {
source-port 100;
destination-port 200;
}
source-prefix-list ipv6-source-users;
destination-prefix-list ipv6-destination-users;
}
}
exp 1;
}
then port-mirror-instance port-mirror-instance1;
then accept;
then count;
}
[edit policy-options]
prefix-list ipv4-source-users {
172.16.1.16/28;
172.16.2.16/28;
}
prefix-list ipv6-source-users {
2001::1/128;
3001::1/128;
}
[edit interfaces]
xe-0/0/1 {
unit 0 {
family inet {
address 100.100.100.1/30;
}
family mpls {
filter {
input mpls-filter;
}
}
}
}
Configuração de espelhamento de porta seletiva
[edit forwarding-options]
port-mirroring {
input {
rate 2;
run-length 4;
maximum-packet-length 500;
}
family any {
output {
interface xe-2/0/2.0;
}
}
}
[edit forwarding-options]
port-mirroring {
instance {
port-mirror-instance1 {
input {
rate 3;
run-length 5;
maximum-packet-length 500;
}
family any {
output {
interface xe-2/0/2.0;
}
}
}
}
}
A interface xe-2/0/2.0 de saída está configurada para a família Camada 2 e não para o MPLS da família.
Para ambos port-mirror e port-mirror-instance ações, a interface de saída deve ser habilitada com a família Camada 2 e não mpls familiar (Camada 3) para que o recurso de espelhamento de portas seletivo funcione.
Configuração de destino espelhada
[edit interfaces]
xe-2/0/2 {
vlan-tagging;
encapsulation extended-vlan-bridge;
unit 0 {
vlan-id 600;
}
}
[edit bridge-domains]
bd {
domain-type bridge;
interface xe-2/0/2.0;
}
Tabela de histórico de alterações
A compatibillidadde com o recurso dependerá da platadorma e versão utilizada. Use o Feature Explorer para saber se o recurso é compatível com sua plataforma.