(Terminando a trilogia) Para fecharmos o assunto, pelo menos por enquanto, vamos ver como configurar o EIGRP. Usaremos a topologia abaixo, onde temos três caminhos de R1 para R5, sendo que de R1 para R2 temos banda e delay padrão, de R1 para R3 temos o delay de 110 e autenticação, e de R1 para R4 estaremos fazendo a sumarização das rotas. Configuração inicial, para referência. R1 hostname R1 interface Loopback0 ip address 10.1.0.1 255.255.255.0 interface Loopback1 ip address 10.1.1.1 255.255.255.0 interface Loopback2 ip address 10.1.2.1 255.255.255.0 interface Ethernet0/0 ip address 192.168.0.2 255.255.255.252 interface Ethernet0/1 ip address 192.168.1.2 255.255.255.252 delay 110 interface Ethernet0/2 ip address 192.168.2.2 255.255.255.252 R2 hostname R2 interface Ethernet0/0 ip address 192.168.0.1 255.255.255.252 interface Ethernet0/1 ip address 192.168.10.1 255.255.255.252 router eigrp 10 network 192.168.0.0 0.0.0.3 network 192.168.10.0 0.0.0.3 R3 hostname R3 interface Ethernet0/0 ip address 192.168.1.1 255.255.255.252 ip authentication mode eigrp 10 md5 ip authentication key-chain eigrp 10 EIGRPPASS interface Ethernet0/1 ip address 192.168.11.1 255.255.255.252 ip authentication mode eigrp 10 md5 ip authentication key-chain eigrp 10 EIGRPPASS router eigrp 10 network 192.168.1.0 0.0.0.3 network 192.168.11.0 0.0.0.3 key chain EIGRPPASS key 1 key-string cisco123 R4 hostname R4 interface Ethernet0/0 ip address 192.168.2.1 255.255.255.252 interface Ethernet0/1 ip address 192.168.12.1 255.255.255.252 router eigrp 10 network 192.168.2.0 0.0.0.3 network 192.168.12.0 0.0.0.3 R5 hostname R5 interface Loopback0 ip address 10.2.0.1 255.255.255.0 interface Loopback1 ip address 10.2.1.1 255.255.255.0 interface Loopback2 ip address 10.2.2.1 255.255.255.0 interface Ethernet0/0 ip address 192.168.10.2 255.255.255.252 interface Ethernet0/1 ip address 192.168.11.2 255.255.255.252 interface Ethernet0/2 ip address 192.168.12.2 255.255.255.252 Existem duas formas de configurar o EIGRP: modo clássico e modo nomeado. R1 será configurado usando o modo clássico (como R2, R3 e R4 foram configurados), e R5 será configurado com o modo nomeado. Configuração R1 Vamos habilitar o EIGRP especificando o AS 10. O AS precisa ser o mesmo entre os roteadores que formarão vizinhança. Na sequência devemos especificar, com o comando network, em quais interfaces o EIGRP será habilitado. Se não for especificada a máscara (wildcard) o EIGRP considera a máscara padrão (classful). conf t router eigrp 10 network 10.0.0.0 network 192.168.0.0 0.0.255.255 Com essa configuração R1 já formará vizinhança com R2 e R4. A vizinhança com R3 ainda não vai funcionar porque precisamos configurar a autenticação. R1#show ip eigrp neighbors EIGRP-IPv4 Neighbors for AS(10) H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num 2 192.168.2.1 Et0/2 10 00:05:56 12 100 0 39 1 192.168.0.1 Et0/0 11 00:05:56 9 100 0 37 R1# Para incrementar nosso exemplo, vamos configurar a autenticação na interface E0/1 (link com R3), utilizando key chain, e fazer a sumarização manual na interface E0/2 (link com R4). Aliás esta é uma vantagem do EIGRP, que nos permite fazer a sumarização em qualquer ponto da rede (diferente do OSPF). conf t key chain EIGRPPASS key 1 key-string cisco123 interface Ethernet0/1 ip authentication mode eigrp 10 md5 ip authentication key-chain eigrp 10 EIGRPPASS interface Ethernet0/2 ip summary-address eigrp 10 10.1.0.0 255.255.0.0 Agora sim podemos ver os 3 neighbors (R2, R3 e R4). R1#show ip eigrp neighbors EIGRP-IPv4 Neighbors for AS(10) H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num 2 192.168.2.1 Et0/2 12 00:00:18 943 5000 0 72 0 192.168.1.1 Et0/1 12 00:18:41 10 100 0 57 1 192.168.0.1 Et0/0 12 00:57:41 7 100 0 55 R1# Também observe que foi criada uma entrada na tabela de roteamento de R1 apontando para Null0, por conta da sumarização. R1#show ip route eigrp Codes: L – local, C – connected, S – static, R – RIP, M – mobile, B – BGP D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2 E1 – OSPF external type 1, E2 – OSPF external type 2 i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2 ia – IS-IS inter area, * – candidate default, U – per-user static route o – ODR, P – periodic downloaded static route, H – NHRP, l – LISP a – application route + – replicated route, % – next hop override Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 7 subnets, 3 masks D 10.1.0.0/16 is a summary, 00:00:05, Null0 192.168.10.0/30 is subnetted, 1 subnets D 192.168.10.0 [90/307200] via 192.168.0.1, 00:59:29, Ethernet0/0 192.168.11.0/30 is subnetted, 1 subnets D 192.168.11.0 [90/309760] via 192.168.1.1, 00:20:30, Ethernet0/1 192.168.12.0/30 is subnetted, 1 subnets D 192.168.12.0 [90/307200] via 192.168.2.1, 00:02:06, Ethernet0/2 R1# Configuração R5 Vamos fazer as mesmas configurações em R5, mas neste caso usaremos o modo “named”. conf t key chain EIGRPPASS key 1 key-string cisco123 router eigrp MyEIGRP address-family ipv4 unicast autonomous-system 10 af-interface Ethernet0/2 summary-address 10.2.0.0 255.255.0.0 exit-af-interface af-interface Ethernet0/1 authentication mode md5 authentication key-chain EIGRPPASS exit-af-interface topology base exit-af-topology network 10.2.0.0 0.0.255.255 network 192.168.0.0 0.0.255.255 exit-address-family Podemos fazer as mesmas verificações que fizemos em R1. R5#show ip eigrp neighbors EIGRP-IPv4 VR(MyEIGRP) Address-Family Neighbors for AS(10) H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num 2 192.168.11.1 Et0/1 14 00:00:45 2 100 0 63 1 192.168.12.1 Et0/2 10 00:02:35 9 100 0 81 0 192.168.10.1 Et0/0 14 00:02:36 9 100 0 61 R5# R5#show ip route eigrp Codes: L – local, C – connected, S – static, R – RIP, M – mobile, B – BGP D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2 E1 – OSPF external type 1, E2 – OSPF external type 2 i – IS-IS,
NSX Load Balancer X-Forwarded-For
(Visibilidade é tudo) O VMWare NSX é uma plataforma de virtualização de rede, e uma das funcionalidades que podemos ter com o NSX é o Load Balancer. Assim como outros balanceadores, o NSX pode trabalhar nos modos One Armed ou Inline. Quando trabalhamos no modo One Armed, o NSX Edge (onde está a funcionalidade de balanceamento de carga) faz source/destinatio NAT. Ou seja, o IP do cliente é mascarado, sendo o IP do balanceador enviado para o servidor. Neste caso acabamos perdendo visibilidade, já que no servidor os logs mostrarão todas as conexões com vindas do balanceador. E este é uma situação comum para todos os balanceadores. X-Forwarded-For Uma forma de contornar este problema, pelo menos quando estamos balanceando HTTP/HTTPS, é utilizarmos o XFF – X-Forwarded-For. O XFF é um cabeçalho HTTP, comumente utilizado para a identificação do endereço IP de origem de clientes que se conectam a servidores web por meio de um balanceador ou servidor proxy. Configurando XFF no NSX A configuração do X-Forwarded-For no NSX resume-se a um checkbox. Para ativar esta função basta selecionar o Edge onde deseja fazer a configuração, clicar na aba Manager > Load Balancer, e então, no menu lateral esquerdo clicar em Application Profile. Selecione o Application Profile desejado e em seguida clique em editar (icone lápis). No Application Profile marque a opção Insert X-Forwarded-For HTTP Header, e Ok. Prontinho. Com esta opção o balanceador passa a inserir o cabeçalho X-Forwarded-For, onde temos o IP do usuário. XFF no servidor Além de configurar o balanceador, a configuração de log do servidor precisa estar “preparada” para mostrar o IP do usuário final. No caso do Apache devemos mudar a configuração no arquivo httpd.conf, conforme exemplo abaixo. Remover a configuração padrão: LogFormat “%h %l %u %t \”%r\” %>s %b \”%{Referer}i\” \”%{User-agent}i\”” combined CustomLog log/acces_log combined Adicionar configuração para mostrar o XFF: LogFormat “%h %l %u %t \”%r\” %>s %b \”%{Referer}i\” \”%{User-Agent}i\”” combined LogFormat “%{X-Forwarded-For}i %l %u %t \”%r\” %>s %b \”%{Referer}i\” \”%{User-Agent}i\”” proxy SetEnvIf X-Forwarded-For “^.*\..*\..*\..*” forwarded CustomLog “logs/access_log” combined env=!forwarded CustomLog “logs/access_log” proxy env=forwarded Com esta mudança podemos olhar os logs no servidor web e confirmar que o IP do usuário está sendo enviado. Note o IP 10.123.45.20, da máquina do usuário que está fazendo o acesso. Também temos “acesso” do IP 10.123.45.164 (balanceador), pois o balanceador acessa o servidor para ver o status do serviço. Estatísticas no Load Balancer (Bônus Track) Podemos ver as estatísticas de utilização do Load Balancer via linha de comando. BrainLB01-0> show service loadbalancer monitor ———————————————————————– Loadbalancer Health Check Statistics: MONITOR PROVIDER POOL MEMBER HEALTH STATUS built-in MyWebPool LABCENTOS01_10.123.45.141 default_http_monitor:L7OK built-in MyWebPool LABCENTOS02_10.123.45.142 default_http_monitor:L7OK built-in MyWebPool LABCENTOS03_10.123.45.144 default_http_monitor:L7OK BrainLB01-0> show service loadbalancer ———————————————————————– Loadbalancer Services Status: L7 Loadbalancer : running ———————————————————————– L7 Loadbalancer Statistics: STATUS PID MAX_MEM_MB MAX_SOCK MAX_CONN MAX_PIPE CUR_CONN CONN_RATE CONN_RATE_LIMIT MAX_CONN_RATE running 5517 0 2082 1024 0 0 0 0 49 ———————————————————————– L4 Loadbalancer Statistics: MAX_CONN ACT_CONN INACT_CONN TOTAL_CONN 0 0 0 0 Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn BrainLB01-0> show service loadbalancer monitor ———————————————————————– Loadbalancer Health Check Statistics: MONITOR PROVIDER POOL MEMBER HEALTH STATUS built-in MyWebPool LABCENTOS01_10.123.45.141 default_http_monitor:L7OK built-in MyWebPool LABCENTOS02_10.123.45.142 default_http_monitor:L7OK built-in MyWebPool LABCENTOS03_10.123.45.144 default_http_monitor:L7OK BrainLB01-0> show service loadbalancer virtual ———————————————————————– Loadbalancer VirtualServer Statistics: VIRTUAL VSHTTP01 | ADDRESS [10.123.45.164]:80 | SESSION (cur, max, total) = (0, 191, 7227) | RATE (cur, max, limit) = (0, 49, 0) | BYTES in = (78424078), out = (396960457) +->POOL MyWebPool | LB METHOD round-robin | LB PROTOCOL L7 | Transparent disabled | SESSION (cur, max, total) = (0, 62, 963499) | BYTES in = (78424078), out = (396958836) +->POOL MEMBER: MyWebPool/LABCENTOS01_10.123.45.141, STATUS: UP | | HEALTH MONITOR = BUILT-IN, default_http_monitor:L7OK | | | LAST STATE CHANGE: 2018-08-03 14:08:58 | | SESSION (cur, max, total) = (0, 21, 321168) | | BYTES in = (26142313), out = (132319866) +->POOL MEMBER: MyWebPool/LABCENTOS02_10.123.45.142, STATUS: UP | | HEALTH MONITOR = BUILT-IN, default_http_monitor:L7OK | | | LAST STATE CHANGE: 2018-08-03 14:08:58 | | SESSION (cur, max, total) = (0, 25, 321166) | | BYTES in = (26141859), out = (132640424) +->POOL MEMBER: MyWebPool/LABCENTOS03_10.123.45.144, STATUS: UP | | HEALTH MONITOR = BUILT-IN, default_http_monitor:L7OK | | | LAST STATE CHANGE: 2018-08-03 14:08:58 | | SESSION (cur, max, total) = (0, 22, 321165) | | BYTES in = (26139906), out = (131998546) BrainLB01-0> Mais informações sobre XFF aqui, e guia para troubleshooting neste link. Até a próxima.
EIGRP Parte 2: DUAL, Feasible Condition e tipos de pacotes
(Tudo seria mais fácil se fossem outros termos) O EIGRP não é um protocolo muito complicado, já falamos um pouco dele neste post, e agora vamos ver mais detalhes de como ele funciona. No decorrer deste post vamos usar a topologia abaixo como exemplo. Neighbor e Topology Table A Neighbor Table é a tabela com informações dos roteadores adjacentes. São armazenados o IP e a interface de cada vizinho, além do HoldTimer anunciado por eles e informações usadas pelo RTP, como número de sequência dos “pacotes confiáveis”. A coluna H mostra o ID associado a cada neighbor do roteador. Address e Interface mostram o IP do neighbor e a interface onde ele está conectado. Hold e Uptime mostram quanto tempo o neighbor tem para enviar um “pacote confiável” e há quanto tempo a adjacência foi estabelecida. SRTT (Smooth Round Trip Time) é o tempo entre enviar um “pacote confiável” e receber a confirmação. Pacote confiável = Update, Query, Reply, SIA-Query, or SIA-Reply O RTO – Retransmit Time Out, é o tempo que o roteador aguardará pela confirmação de um pacote unicast retransmitido após a entrega anterior não ter sido confirmada. Se o RTO expirar antes de um ACK ser recebido, outra cópia do pacote é enviada. Assim como no SRTT, o tempo é mostrado em milissegundos. O Q Cnt indica o número de pacotes que foram preparados para envio/enviados, mas para os quais não foram recebidos ACKs. Em uma rede estável, o valor Q Cnt deve ser zero. E por fim o Seq Num, que mostra o número de sequência do último “pacote confiável”. Já a Topology Table é onde o EIGRP armazena as informações de roteamento, incluindo o prefixo de cada rede conhecida, Feasible Distance para os destinos, endereços dos roteadores vizinhos e a interface de saída para cada neighbor. Cada rede na Topology Table pode ter o estado Passive, significando que o caminho mais curto para a rede já foi encontrado, ou pode ter o estado Active, quando o EIGRP está buscando a melhor rota para a rede. Reported Distance e Computed Distance Reported Distance (RD) corresponde a distância (métrica) do vizinho até o destino anunciado. Podemos ver a métrica deste vizinho até o destino usando os comandos sh ip eigrp topology, sh ip eigrp topology all-links ou ainda sh ip eigrp topology A.B.C.D/nn. O RD é o número entre parênteses, depois da ”/”, nos outputs destes comandos. A Computed Distance (CD) corresponde ao RD + o custo do link entre o roteador e seu vizinho. O CD é o número antes da barra, também entre parênteses, nos mesmos comandos citados acima. Considerando nossa topologia de exemplo, temos 4 caminhos de R1 para as redes 10.2.X.0/24. Vamos olhar a rede 10.2.0.0 especificamente. R2 e R3 tem o mesmo custo (281632) para chegar à rede 10.2.0.0, mas R1 tem custo menor para chegar à R2 do que à R3 (isso porque o delay na interface eth0/0 de R1 é 100, e na eth0/1 é 110). O objetivo do EIGRP, assim como dos outros protocolos de roteamento dinâmico, é encontrar o caminho com menor custo para cada destino. Assim, a rota com o menor CD é colocada na tabela de roteamento. Lembre-se que o EIGRP faz o balanceamento automaticamente entre rotas com o mesmo custo, e poderia fazer o balanceamento entre caminhos com custos diferentes, se fosse configurado para isso. DUAL e Feasible Condition O Diffusing Update Algorithm (DUAL), é o algoritmo usado pelo EIGRP para convergência da rede. Ele incorpora mecanismos para garantir a escolha de caminhos sem loop, e seleciona as rotas que devem ser colocadas na tabela de roteamento. Esta parte é um pouco confusa, acredito que mais por causa dos termos utilizados do que pelo funcionamento em si. Feasible Distance: Tanto o CD quanto o RD são as métricas atuais para o destino. Já o Feasible Distance é o registro da menor métrica para cada destino, desde a última vez que a rota foi computada (passou de ativa para passiva). Esta informação tem valor apenas local e nunca é anunciada. Feasible Condition: É a regra que garante que o caminho pode ser usado sem formar loop de roteamento. A condição é a seguinte: um neighbor que anuncia um a rota com RD menor do que meu Feasible Distance, é um caminho seguro (sem loop) para o destino. Feasible Successor: Todo vizinho que atende a Feasible Condition (sabidamente um neighbor que pode ser usado para alcançar um destino sem provocar loop), é considerado um Feasible Successor. Successor: Dentre os Feasible Successors, o vizinho (ou os vizinhos) com o menor CD (Computed Distance) será considerado Successor. De volta ao nosso exemplo, podemos confirmar que R2 e R3 são Feasible Successors, isto é, atendem a Feasible Condition. E R2 é o Successor, neighbor com menor custo para o destino. Usando o comando show ip eigrp topology, sem especificar a rede, também podemos validar que apenas R2 e R3 passaram na Feasible Condition. Importante notar que roteadores que atendem a Feasible Condition são roteadores que fornecem caminhos garantidamente sem loop. No entanto, roteadores que não atendem a FC podem eventualmente também fornecer caminho sem loop (como é o caso do nosso exemplo inclusive). O que acontece é que o EIGRP usa a Feasible Condition também para garantir a rápida convergência. Ou seja, todos os roteadores que atendem a FC estão “prontos” para serem usados. Assim, no caso de falha do R2, o tráfego passaria a ser encaminhado por R3 quase que instantaneamente. Se R3 também falhar, aí R1 precisará passar a rota para o estado ativo, perguntar para os neighbors quem conhece a rede, identificar a nova Feasible Distance e então ver quem, neste novo cenário, atende a FC. Obviamente neste caso a convergência não seria tão rápida quanto no caso anterior. Pacotes EIGRP O EIGRP usa seis tipos de pacotes para comunicação “normal” entre os roteadores, e ainda dois tipos “especiais” (SIA), conforme descrito abaixo. Hello: Pacotes usados para detectar e manter adjacência. São enviados para o
EIGRP Parte 1: Métrica
(KKKKK) O EIGRP – Enhanced Interior Gateway Routing Protocol, é um protocolo de roteamento dinâmico, do tipo distance vector. Antes dele tínhamos o IGRP (Interior Gateway Routing Protocol), protocolo criado pela Cisco, análago ao RIP, e que fazia o anúncio do database inteiro a cada update. O anúncio servia tanto para trocar informações de roteamento, como para construir e manter vizinhança. O EIGRP é uma evolução do IGRP, e uma das diferença é justamente o fato de o EIGRP separar as funções de detecção de vizinhança, e informações de roteamento. O EIGRP também foi criado pela Cisco, e em 2013 foi publicado como IETF Internet Draft, permitindo outros fabricantes implementá-lo. Com a separação destas duas funções, no EIGRP temos o Hello para detectar a presença de roteadores vizinhos e manter a adjacência. Os pacotes Hello são enviados de tempos em tempos (5 segundos em redes ethernet, 60 segundos em redes NBMA com banda menor que 1544 kbps), como no OSPF, e não carregam nenhuma informação de roteamento. E temos o HoldTimer, tempo de espera até o próximo Hello. Se o roteador não receber um Hello neste tempo (por padrão 3x o Hello), o vizinho é considerado down. Para formar adjacência os roteadores precisam: Fazer autenticação EIGRP (se configurado) Ter os mesmo valores dos “Ks” Estar no mesmo Sistema Autônomo Usar IP primário para estabelecer a relação Estarem na mesma rede Para anunciar as rotas, o EIGRP utiliza o RTP – Reliable Transport Protocol, que é o protocolo IP 88 (não é o mesmo usado para media streaming – Real Time Protocol). O RTP permite a troca de tabelas de roteamento completa, inicialmente quando uma adjacência é criada, e depois a troca de updates incrementais, contendo apenas as mudanças. E os updates são gerados apenas quando ocorrem mudanças na tabela de roteamento (nova rota inserida/aprendida, rede removida ou mudança em uma rota existente), o que faz o protocolo consumir pouca banda. No EIGRP temos rotas internas, inseridas no processo EIGRP via comando network, e que tem distância administrativa de 90 (padrão) e rotas externas, aprendidas de outras formas (redistribuição, por exemplo). Neste caso a distância administrativa é 170. Outras características: Suporta classless e VLSM Sumarização de rotas (habilitado por padrão) Suporta balanceamento, inclusive entre caminhos com métricas diferentes Usa multicast (224.0.0.10) para descobrir vizinhos automaticamente Se o neighbor é cadastrado manualmente (redes que não suportam multicast nativamente), usa uniscat para comunicação Métrica Clássica O EIGRP usa como métrica o resultado de uma equação que pode usar a Banda (Bandwidth), Delay, Confiabilidade (Realiability), Carga (Load) e MTU, e ainda podemos definir o número máximo de saltos (Hop Count). Bandwidth: definido pelo comando bandwidth aplicado na interface (se não for configurado o IOS considera valores padrões para cada tipo de interface). É considerado o menor valor olhando o caminho todo para determinado destino. Delay: valor configurado na interface, e se não definido o IOS associa um valor implícito, de acordo com o tipo da interface. Na configuração é utilizada a medida “dezenas de microsegundos”, enquanto na saída de comandos shows o delay é mostrado em microssegundos. Ou seja, nos comandos shows será mostrado um valor 10 vezes maior do que o configurado. O EIGRP soma o delay do caminho todo para compor a métrica. Para indicar um destino inalcançável, podemos configurar o delay máximo (16,777,215 dezenas de microssegundos). Aliás é assim que o Split Horizon com Poisoned Reverse (Route Poisoning) trabalha. Realiabitliy: a confiabilidade é estimada dinamicamente, com base na relação dos pacotes recebidos com sucesso e total de pacotes recebidos. 255 representa uma interface 100% confiável, e o EIGRP leva em conta a menor confiabilidade do caminho. Na prática este item foi herdado do IGRP, e por padrão não é levado em conta no calcula da métrica. Load: Valor estimado dinamicamente, com base na utilização da interface. Uma interface 100% utilizada tem o valor 255. Assim como a confiabilidade, este item não é levado em conta por padrão. MTU: Teoricamente seria levado em conta o menor valor de MTU no caminho, mas apesar da informação ser divulgada no EIGRP, o uso deste item nunca foi de fato implementado. Hop Count: é contagem de saltos no caminho, pode ser configurado um valor máximo (até 255). Serve como um limite para os anúncios EIGRP (e segundo mecanismo de segurança para evitar loop), mas não é levado em conta no cálculo da métrica e não influencia na escolha do melhor caminho. Valores K Os “Ks” (ou K-values) são 5 constantes que são usadas para dar peso a cada item da métrica. Podemos escolher valores de 0 a 255 para cada um dos Ks para influenciar o impacto de cada um dos itens que compõem a métrica. Como vimos anteriormente, para estabelecer adjacência os roteadores precisam ter os mesmos valores nos Ks. Por padrão, K1 e K3 tem o valor 1, e os demais são configurados com 0, fazendo com que o EIGRP considere apenas bandwidth e delay no cálculo da métrica. Cálculo da Métrica O EIGRP calcula a métrica com base na formula abaixo. Sendo que: K1 = K3 = 1 K2 = K4 = K5 = 0 BWs (Bandwidth Scale) = quantas vezes menor do que 107 kbps x 256, é a banda mínima no caminho. Ds (Delay Scale) = soma do delay no caminho x 256. LoMax = máximo load no caminho. RMin = menor confiabilidade verificada na rota. A multiplicação da banda e do delay é apenas para transformar a métrica em 32 bits, já que anteriormente o IGRP usava um métrica de 24 bits. Note também que nem MTU nem número de saltos entra na conta, e considerando os valores padrões para os Ks, podemos confirmar que o cálculo levará em consideração apenas banda e delay. Wide Metrics As métricas clássicas consideravam interfaces de no máximo 1 Gbps, e acima disso tínhamos o mesmo valor. Ou seja, não dava para diferenciar uma interface 10 Gbps de uma de 100 Gbps. O delay para interfaces de 1 Gbps
Convertendo ASA OS para Firepower Threat Defense (reimage)
(Like a monk) Antes de mais nada, vamos relembrar os termos utilizados, já que tivemos algumas mudanças nos últimos anos. ASA: Nome dos appliances criados já há alguns anos. Hoje temos a família 5500-X. ASA OS: Sistema operacional que rodava originalmente nos appliances ASA. Tem funcionalidade de firewall e VPN basicamente. Firepower: Novos appliances (série 2100, 4100 e 9300), onde podemos instalar o FTD ou mesmo o ASA OS. FTD (Firepower Threat Defense): Novo software (NGFW/NGIPS), que pode ser instalado nos appliances Firepower ou nos ASA. FMC (Firepower Management Center): Software para gerência dos appliances que rodam FTD. Pode ser um appliance físico ou virtual. FDM (Firepower Device Manager): Software para gerência local dos appliances com FTD. O Cisco ASA foi o firewall mais vendido do mundo, e por muitos anos fez muito bem seu papel. No entanto, com as novas tecnologias e ameaças, acabou ficando obsoleto. A Cisco então adquiriu a Sourcefire, e juntou as funcionalidades do software da Sourcefire com o ASA OS, criando o FTD. Ainda existe um modelo “híbrido”, onde podemos ter em alguns appliances o ASA OS rodando junto com o Firepower Service Module, mas esta opção tente a deixar de existir com o tempo. Felizmente esse novo software (FTD) pode ser instalado tanto nos novos appliances (Firepower) quanto nos velhos ASA5500X. E justamente por isso, é natural fazermos a troca do ASA OS para o FTD em algum momento. Migrando ASA5515X para FTD Este procedimento foi executado em um ASA5515X, mas com pequenas mudanças serve também para os demais modelos (ASA 5506-X, ASA 5506W-X, ASA 5506H-X, ASA 5508-X, ASA 5512-X, ASA 5515-X, ASA 5516-X, ASA 5525-X, ASA 5545-X, ASA 5555-X, ISA 3000 e Firepower 2100). 1) Copie o arquivo de boot do FTD para o ASA, usando um TFTP Server (nos modelos ASA 5506-X, 5508-X, 5516-X, ISA 3000 é necessário usar a interface M1/1). 2) Apague todos os outros arquivos de boot do ASA, deixando apenas o que acabou de copiar. 3) Reinicie o ASA. 4) O ASA vai incializar com o novo arquivo de boot 5) Digite setup e faça a configuração básica para termos acesso ao FTP Server e então instalar o FTD. 6) Verifique a conectividade com o FTP Server. 7) Copie o FTD para o ASA e então reinicie o ASA. 8) O ASA vai inicializar com o novo software (FTD), e pedirá para que mude a senha e configure a rede. 9) Verifique a configuração. 10) Pronto. A partir daqui pode acessar a interface gráfica direto no ASA (FDM, imagem abaixo) ou registrar o ASA no FMC. Importante: Os modelos ASA 5506-X, ASA 5506W-X, ASA 5506H-X, ASA 5508-X, ASA 5512-X, ASA 5515-X, ASA 5516-X, ASA 5525-X, ASA 5545-X, ASA 5555-X, ISA 3000 e Firepower 2100 suportam este procedimento. Os Firepowers 4100 e 9300, também podem ser convertidos, mas temos que usar outro procedimento. Também é possível fazer o reimage através da rommon. O arquivo de boot do FTD para ASA 5506-X, ASA 5508-X, ASA 5516-X e ISA 3000 tem a extensão .lfbff. Já os demais modelos usam um arquivo com extensão .cdisk. Este processo apaga completamente as configurações do ASA. Será necessário a reconfiguração do equipamento. Nos modelos ASA 5512-X até 5555-X o FTD deve ser instalado no SSD. É necessário usar a rommon 1.8 ou superior antes de migrar para FTD. Não dá para fazer o upgrade da rommon depois de fazer a mudança para FTD. Também é possível fazer o processo contrário (equipamento com FTD voltar para ASA OS). Mais informações aqui. Até a próxima.
Demo Cisco DNA-Center
(Tudo novo) Vídeo com overview da interface do Cisco DNA-Center, o software para administração da LAN. Nele construímos a Fabric, configuramos underlay e o overlay, além de fazermos a segmentação da rede. O DNAC ainda tem a função de Analytics e Assurance, que além de melhorar a visibilidade ainda ajuda na correção de problemas. Até a próxima.
