Nota: Este Post faz parte do guide de Routing.
Chapter 2 Load Balancing and Filter-Based Forwarding
Equal-cost Multipath Load Sharing (ECMP)
Usando ECMP a entrega dos pacotes pode chegar ao destino out-of-order
Per-Packet Load Balancing
Faz forwarding dos pacotes em round-robin mode, o junOS não suporta o forwarding per-packet
Per-Flow Load Balancing
Permite que os pacotes sigam o mesmo path, não exisitndo pacotes out-of-order.
Todos os protocolos (não apenas TCP) podem beneficiar deste mecanismo.
Default Behavior for the junOS OS
No IGP load-balancing o junOS escolhe um dos available equal-cost paths para os qual o tráfego de destino será enviado, desta forma e possível saber sempre (any time) por onde o tráfego flui.
Quando existem existem multiple equal-cost paths o junOS seleciona um next-hop e instala-o na forwarding table.
By default no BGP o método de load-balancing e ligeiramente diferente, e usado o per-prefix. O per-prefix load-balancing ocorre quando as rotas são recebidas via iBGP com os atributos (next-hop) idênticos
não e garantido uma distribuição perfeita do tráfego devido ao algoritmo (hash) para selecionar o next-hop para um prefixo dado. A distribuição efectiva aumenta com um grande numero de prefixos.
Nota:E possível alterar o comportamento do load-balancing usando policy rules
Configuration Examples
! O junOS apenas faz load-balancing para os prefix abaixo
set policy-options policy-statement load-balance-all from route-filter 172.24.0.0/24 exact
set policy-options policy-statement load-balance-all from route-filter 172.24.1.0/24 exact
set policy-options policy-statement load-balance-all then load-balance per-packet
Esta policy deve ser aplicada como export sob a hierarquia routing-options
Nos Internet Processor II ASIC suportam ate 64 ECMP, os tráfego de destino e encaminhado pela mesmo interface outbound com base em algumas características do flow
Nos Internet Processor I ASIC (plataformas legacy) suportam até 8 ECMP, o balanceamento é feito per-packet. O tráfego é distribuído em round-robin usando diversas outbound interfaces
Applying a Load-Balancing Policy
Aplicar load-balacing afeta apenas a forwarding table.
É possível manipular a forwarding table usando uma policy
set routing-options forwarding-table export <policy-name>
RE{RT—Export—>FT—->} PFE{FT}
Determining Traffic Flows
By default o junOS considera que o trafego ingress com os características abaixo pertencem ao mesmo flow:
Incoming interface Index | Destination Address
Source Address | Protocol
!Incluir o layer 4 no calculo do flow, deve ser config o layer3 caso seja usado o layer4
set forwarding-options hash-key family inet layer-3 layer-4
Também é possível optimizar MPLS e VPLS flows usando set family mpls e set family multiservice
By default o IPv6 e automaticamente balanceado usando Layer3/Layer4
Filter-Based Forwarding
Permite tomar decisões com base no prefixo destino
Suportado em IPv4 e IPv6
Configuring Filter-Based Forwarding
1.Criar um match filter sob a hierarquia firewall
2.Criar uma routing instance sob a hierarquia routing-instances
3.Criar um RIB Group sob a hierarquia routing-options Partilha as rotas entre instances assim os directly connected nex-hop podem ser resolved
1)
!Este exemplo permite fazer forwarding do trafego para a instance indicada, deve ser ainda configurado no input da interface onde este trafego e recebido
set firewall family inet filter <filter-name> term <term-name> from match-condition
set firewall family inet filter <filter-name> term <term-name> then routing-instance <instance-name>
2)
!Para usar filter-based o instance-type deve ser sempre forwarding
set routing-instances <instance-name> instance-type forwarding routing-options static route 0.0.0.0/0 next-hop <ip-address>
!Tambem e possivel indicar outra routing instance usando next-table
set routing-instances <instance-name> instance-type forwarding routing-options static route 0.0.0.0/0 next-table inet.0
3)
!Esta config partilha as rotas das interfaces entre as instances referidas. Este requisito consegue resolver directly connected next hops
set routing-options interface-routes rib-group inet <group-name>
set routing-options rib-groups <group-name> import-rib [inet.0 instance-name.inet.0]
Neste passo e criada a routing table (ou RIB group) que adiciona interfaces routes a forwarding routing instances usadas no FBF bem como a instance default inet.0 . Esta config resolve as rotas instaladas nas instances directly connected next hops nessa interface
Exemplo: Usar FBF para balancear tráfego com base no source address
R1}-ge-0/0/2—ISP-A
R1}-ge-0/0/3—ISP-B
set firewall family inet filter my-match-filter term match-subnet-A from source-address 172.25.0.0/24
set firewall family inet filter my-match-filter term match-subnet-A then routing-instance ISP-A
set firewall family inet filter my-match-filter term match-subnet-B from source-address 172.25.1.0/24
set firewall family inet filter my-match-filter term match-subnet-B then routing-instance ISP-B
set interfaces ge-0/0/8 unit 0 family inet filter input my-match-filter
set interfaces ge-0/0/8 unit 0 family inet address 172.25.0.1/24
set interfaces ge-0/0/8 unit 0 family inet address 172.25.1.1/24
set routing-instances ISP-A instance-type forwarding routing-options static route 0.0.0.0/0 next-hop 172.20.0.2
set routing-instances ISP-B instance-type forwarding routing-options static route 0.0.0.0/0 next-hop 172.20.1.2
Exemplo: Configure the RIB Group
set routing-options interface-routes rib-group inet my-rib-group
set routing-options rib-groups my-rib-group import-rib [inet.0 ISP-A.inet.0 ISP-B.inet.0]
Nota:A default route também e incluída
user@R1> show route table ISP-B.inet.0
ISP-B.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, – = Last Active, * = Both
0.0.0.0/0 *[Static/5] 03:32:41
> to 172.20.1.2 via ge-0/0/3.0
172.20.0.0/30 *[Direct/0] 03:32:41
> via ge-0/0/2.0
172.20.0.1/32 *[Local/0] 03:19:07
Local via ge-0/0/2.0
172.20.1.0/30 *[Direct/0] 03:32:41
> via ge-0/0/3.0
172.20.1.1/32 *[Local/0] 03:19:09
Local via ge-0/0/3.0
172.25.0.0/24 *[Direct/0] 03:32:41
> via ge-0/0/1.0
172.25.0.1/32 *[Local/0] 03:19:09
Local via ge-0/0/1.0
172.25.1.0/24 *[Direct/0] 03:32:41
> via ge-0/0/1.0
172.25.1.1/32 *[Local/0] 03:19:09
Local via ge-0/0/1.0
Então e se a rede source fosse 172.26.1.0/24???
Seria Droped uma vez que não existe Firewall rule a permitir, caso fosse aplicada a config abaixo o lookup seria com base no destino a default routing table
[edit firewall]
user@R1# show family inet filter my-match-filter
term match-subnet-A {
from {
source-address {
172.25.0.0/24;
}
}
then {
routing-instance ISP-A;
}
}
term match-subnet-B {
from {
source-address {
172.25.1.0/24;
}
}
then {
routing-instance ISP-B;
}
}
term else-accept {
then {
accept;
}
}
Usando a opção instance-import
A config usando rib-group apesar de ter performance, esta técnica tem algumas limitações:
Lack of intuitiveness – não é muito intuitivo
Complex configuration requirements
Redundancy
Per-protocol configuration
set policy-options policy-statement ISP-A-import from instance master
set policy-options policy-statement ISP-A-import then accept
set routing-instances ISP-A instance-type forwarding routing-options static route 0.0.0.0/0 next-hop 172.20.0.2
set routing-instances ISP-A instance-type forwarding routing-options instance-import ISP-A-import
Multitopology Routing Basics
Nota:não disponível nos EX
Permite configurar class-based forwarding para diferentes tipos de tráfego voice, video, etc. Permite ter uma tabela de routing para cada tipo especifico de tráfego
Configuring Topologies
set routing-options topolgies family inet topology my-video-topology
Cada topology cria uma nova routing table e popula-a com direct routes da topology
Configuring Filter-Based Forwarding for Multitopology Routing
set firewall family inet filter my-match-filter term term-name from forwarding-class expedited-forwarding
set firewall family inet filter my-match-filter term term-name then topology my-video-topology
E configurado um firewall filter no ingress para mapear para uma forwarding class especifica
Podem ser usadas uma das 4 forwarding-class:
expedited-forwarding
assured-forwarding
best-effort
network-control
Referências:
Notas estudo JNCIS-ENT parte 1
Notas estudo JNCIS-ENT parte 2
Notas estudo JNCIS-ENT parte 3
Notas estudo JNCIS-ENT parte 4
Notas estudo JNCIS-ENT parte 5
1 thought on “Notas estudo JNCIS-ENT parte 8”