(Melancolia que não acaba) No último dia 18 entramos no 9º ano do blog e acabei não percebendo (não sei porque mas eu jurava que tínhamos começado em outubro). Quando começamos quase “tudo isso aqui era mato”. De lá para cá surgiram centenas de outros blogs de rede. Muitos são ótimos, sempre leio e recomendo. Muitos outros começaram e desistiram. Continuar um blog por 8 ano, seja qual for o tema, não é assim tão comum. Mais difícil ainda com um conteúdo tão específico. Geralmente continuam existindo somente os que vendem algo, ou estão atrelados a uma empresa (e isso não é uma crítica). Cuidar do blog virou parte da minha rotina. Todo dia entro, vejo os comentários, respondo quando consigo, e eventualmente posto algo. Já tivemos um período com mais visitantes (quando postava com mais frequência). Mas no nosso ritmo continuamos. Nestes 8 anos tivemos meio milhão de visitantes, com um pouco mais de 1.500.000 de visualizações. Não é nada, não é nada, não é nada mesmo. Obrigado a todos que colaboraram com conteúdo e também aos que vez ou outra dão uma passadinha por aqui. Curiosidade De setembro a dezembro de 2008 o browser mais utilizado para acessar o blog foi o Internet Explorer, com o Firefox em segundo. O Chrome aparecia em 3º (foi lançado em dezembro daquele ano), e o Opera fecha a lista. Neste mês os visitantes já usaram 10 diferentes browsers para acessar o blog, com o Chrome em primeiro (ampla vantagem), Firefox em segundo e IE em terceiro. Ainda registramos Safari, Edge, Opera, Android Browser, UC Browser, Safari (app) e Opera Mini, na ordem. Até a próxima.
Configurando Etherchannel entre switches Cisco e VMware ESXi
Já a algum tempo a virtualização de servidores tornou-se comum. Junto com ela a necessidade de fazermos um etherchannel entre os hosts (servidores físicos) e o switches. A configuração é simples, e do lado do switch bem comum para quem trabalha com redes, mas é necessário observar um detalhe: devemos usar o comando channel-group “X” mode on. Apesar de normalmente não recomendarmos o uso do mode on, neste caso faz-se necessário, uma vez que o Standard Vswitch (switch virtual padrão do vSphere) não suporta LACP. Quando usamos LACP, ele verifica se todos os links agrupados estão conectados no mesmo equipamento na outra ponta, e por isso é recomendado seu uso. Quando usamos o mode on, nenhum tipo de verificação é feita. Seguem dois exemplo de configuração (porta acesso e porta trunk) de etherchannel em switches Cisco. Etherchannel Porta de Acesso (apenas uma VLAN, não muito usando neste tipo de ambiente):interface Port-channel1switchportswitchport access vlan 100switchport mode accessspanning-tree portfast!interface GigabitEthernet1/1switchportswitchport access vlan 100switchport mode accessspanning-tree portfastchannel-group 1 mode on!interface GigabitEthernet1/2switchportswitchport access vlan 100switchport mode accessspanning-tree portfastchannel-group 1 mode on Etherchannel Porta Trunk (mais de uma VLAN, configuração mais comum):interface Port-channel2switchportswitchport trunk encapsulation dot1q (alguns switches não precisam deste comando)switchport mode trunkswitchport trunk native vlan 10 (opcional, depende do ambiente, mas é recomendado)switchport trunk allowed vlan 10,15,20,192,200 (opcional, mas recomendado – colocar apenas as vlans usadas no host)spanning-tree portfast trunk!interface GigabitEthernet1/5switchportswitchport trunk encapsulation dot1q (alguns switches não precisam deste comando)switchport mode trunkswitchport trunk native vlan 10 (opcional, depende do ambiente, mas é recomendado)switchport trunk allowed vlan 10,15,20,192,200 (opcional, mas recomendado – colocar apenas as vlans usadas no host)spanning-tree portfast trunkchannel-group 2 mode on!interface GigabitEthernet1/6switchportswitchport trunk encapsulation dot1q (alguns switches não precisam deste comando)switchport mode trunkswitchport trunk native vlan 10 (opcional, depende do ambiente, mas é recomendado)switchport trunk allowed vlan 10,15,20,192,200 (opcional, mas recomendado – colocar apenas as vlans usadas no host)spanning-tree portfast trunkchannel-group 2 mode on Interessante que alguns documentos da Cisco apontam para o uso do channel-group mode X passive, o que acaba levando a erro na configuração (e ao não funcionamento). Do lado do servidor, através do vSphere, escolha o host que será configurado e, no standard switch utilizado clique em Properties, depois em Edit e então selecione a aba NIC Teaming. Na opção Load Balance selecione Route Based on IP Hash. Na parte de baixo da janela (Failover Order) coloque as placas de rede como ativas. Importante notar que estamos falando da configuração do Standard Vswitch, mais simples e comum. Caso o ambiente de virtualização utilize Distributed Vswitch ou algum tipo Fabric Interconnect que suporte LACP, a configuração pode ser diferente (channel-group 1 mode active, por exemplo). Referência: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1004048 Até a próxima.
12 verdades sobre redes de computadores (RFC 1925)
Request for Comments – RFC, é um tipo de publicação do Internet Engineering Task Force (IETF) e Internet Society (ISOC), principais órgãos de definição de padrões de desenvolvimento e técnica para a Internet. Os fabricantes de equipamentos/sistemas seguem as RFCs (além de ajudar nas especificações) e isso nos permite usar equipamentos de marcas diferentes sem maiores problemas. Além deste trabalho de padronização, no dia 1º de abril de cada ano o IETF publica algumas RFCs. E este é o caso da RFC 1925, publicada em 1996, que trata sobre as verdades das redes de computadores. Veja se vocês concordam com esta RFC: (1) Tem que funcionar. (2) Por mais que você de duro, e não importa qual a prioridade, não é possível aumentar a velocidade da luz. (2a) Não importa o quão duro você tente, você não pode fazer uma bebê em muito menos de 9 meses. Tentar acelerar o processo pode torná-lo mais lento, não mais rápido. (3) Com impulso suficiente os porcos voam muito bem. No entanto, esta não é necessariamente uma boa ideia. É difícil ter certeza de onde eles vão pousar, e poderia ser perigoso sentar onde eles sobrevoam. (4) Algumas coisas na vida não podem ser totalmente apreciadas ou entendidas a menos que você experimente em primeira mão. Algumas coisas na rede não podem ser plenamente compreendidas por alguém que nem constrói equipamentos de rede, nem administra uma rede. (5) É sempre possível juntar vários problemas distintos em uma única solução interdependentemente complexa. Na maioria dos casos isto é uma má ideia. (6) É mais fácil mover um problema (por exemplo, mover o problema para uma parte diferente da rede) do que resolvê-lo. (6-A) É sempre possível adicionar outros níveis indiretos. (7) É sempre algo: (7a) Bom, rápido e barato: escolha dois (você não pode ter todos os três). (8) É mais complicado do que você pensa. (9) Para todos os recursos, seja o que for, você precisa de mais. (9a) Todo problema de rede sempre leva mais tempo para resolver do que deveria. (10) Um tamanho não serve para todos. (11) Cada ideia antiga será proposta novamente com um nome diferente e uma apresentação diferente, independente se funciona ou não. (11a) Ver regra 6a. (12) Na concepção de protocolos, a perfeição é alcançada não quando não há mais nada a acrescentar, mas quando não há mais nada para tirar. Já conheciam a RFC 1925? Concordam com ela? Até a próxima.
Como funciona o Spanning-Tree Protocol
(Oito anos de blog e não tínhamos um post falando de Spanning-Tree) O STP – Spanning-Tree Protocolo, é utilizado pelos switches para evitar loops de camada 2. Basicamente o STP bloqueia caminhos redundantes, evitando assim a formação de loops. Aliás, justamente por causa deste comportamento (bloquear caminhos) que em algumas redes (data centers, por exemplo) o STP é abolido. Ainda é assim, ele é fundamental para o bom funcionamento de redes “convencionais”, também chamadas de campus network (tradicionalmente aquele design 3 camadas, com acesso, distribuição e core). Para o STP funcionar o primeiro passo é eleger um switch root, e isso é feito da seguinte forma: Quando os switch são ligados todos eles se consideram o root bridge. E como um político, todos passam a divulgar que são os melhores, ou no caso gerar e enviar Configuration BPDUs – Bridge Protocol Data Units a cada 2 segundos (hello timer) informando: Root Bridge ID (RBID) Root Patch Cost (RPC) Sender Bridge ID (SBID) Sender Port ID (SPID) Receiver Port ID (RPID) Quando um switch vizinho recebe um Configuration BPDU ele compara com suas próprias informações (e de outros BDPUs recebidos) para identificar qual é o “melhor” de fato. Se o Root Bridge ID do BPDU recebido é o menor, o switch entende há um candidato à root bridge melhor do que ele mesmo. Neste momento ele para de gerar e enviar BPBUs e passa apenas a encaminhar (incrementando os comandos necessários) os BPDUs deste candidato (diferente dos políticos…). Este processo se repete até que todos os switches parem de enviar seus próprios BPDUs e passem a encaminhar os BPDUs de um único switch. Com isso temos então eleita o root bridge. O Bridge ID é formado pela prioridade (32.768 por padrão, mas que pode ser configurada em múltiplos de 4096) + ID da VLAN + Mac Address do Switch. Este formato, considerando a VLAN, é chamado System ID Extension (ou Mac Address Reduction) e permite termos instancias STP diferentes por VLAN (PVSTP+). Também vale lembrar que por padrão este é o formato usado pelos switches Cisco, e podemos confirmar isso olhando o show running-config (observe o comando spanning-tree extend system-id). O próximo passo é eleger as portas root (portas com menor custo para chegar a root bridge). Para isso temos um processo parecido com descrito acima, onde os switches (não roots) comparam os BPDUs, mas agora a comparação vai ser nos demais campos, já que todos os BPDUs terão (possivelmente) o mesmo RBID. A porta que receber o BPDU com o menor RPC será escolhida como root port. Caso duas ou mais portas recebam BPDUs com o mesmo RBID e mesmo RPC, o switch compara então o próximo campo (SBID). Se houver empate, compara o próximo campo… Como o último campo é o ID da porta que recebeu o BPDU, não tem como haver empate (se as portas 1 e 2 receberem BPDUs “iguais”, a porta 1 será a porta root). Hellos BPDUs recebidos na porta root são encaminhados para as portas designadas, com o custo (RPC), SBID e SPID alterados. Hellos recebidos em outras portas (não roots) são processados, mas não encaminhamos. E os switches também não encaminham hellos pelas portas roots e portas que estão em blocking. Por fim, após escolher a porta root, o switch escolherá as portas designadas / bloqueadas em cada segmento. Para ter porta designada em um seguimento o switch precisar encaminhar o “melhor” BPDU no referido segmento (ter o menor RBID, ou RPC, ou SBID, …). Topologia com STP: Rede sem loop, mas muitos caminhos bloqueados. Mudança na topologia Quando ocorre uma mudança na topologia (outro switch torna-se root, uma interface passa de Learning ou Forwarding para Blocking, uma porta vai para Forwarding ou um Topogoly Change Notification é recebido), o switch que detectou a mudança passa a enviar BPDUs com as informações apropriadas, e os switches vizinhos, ao receber essas informações, vão processar estes BDPUs (podendo repensar suas escolhas) e encaminhá-los. Complementarmente o switch que detectou a mudança envia um TCN – Topology Change Notification BPDU com intenção de notificar o switch root. Cada switch que recebe o TCN devolve um TCA- Topology Change Acknowledge e passa o TCN para frente, até que chegue ao root. O root por sua vez notifica então todos os switches (lembre-se que somente o switch root envia Configuration BPDUs), para que eles removam as entradas não usadas da tabela CAM (e consequentemente aprendam os MACs pelas novas interfaces que estão em forwarding). Todo esse processo descrito acima, refere-se ao padrão 802.1D original (já não suportado em equipamentos Cisco). Porém é importante conhecê-lo já que mesmo os outros padrões tem conceitos semelhantes. Além do 802.1D (originalmente STP), tínhamos o 802.1W que definia o RSPT e o 802.1S (MST). Posteriormente isso mudou. O padrão 802.1D-2004 recebeu melhorias e passou a definir o RSTP, enquanto o MST foi integrado ao padrão 802.1Q-2005. Mesmo assim ainda hoje é normal falar de 802.1D referindo-se ao STP original. Até a próxima.
Otimizando o Spanning-Tree Protocol
O Spanning-Tree Protocol tem um papel fundamental nas redes “campus”, evitando ocorrência de loops de camada 2, ou pelo menos minimizando as chances deles acontecerem. Fora a utilização do protocolo em sí, com seus vários sabores (STP, PVSTP, RSTP, MST, RPVSTP), podemos habilitar algumas funções nos switches Cisco que farão a rede mais rápida e menos propensas a loops. Portfast (port type edge): O comando spanning-tree portfast (spanning-tree port type edge) usado no modo interface é provavelmente o mais conhecido desta lista. Ele foi introduzido pela Cisco, como melhoria no STP e PVSTP+. Posteriormente foi adicionado aos padrões RSTP e MST. Este comando faz com que a porta passe para Forwarding imediatamente após ficar UP. Portas Edges enviam BPDU, mas não devem receber (não devem ser conectadas à switches). Se uma porta Edge receber BPDU, o Portfast é “desabilitado” e a porta faz o processo normal do STP. Usar o Portfast com o RSTP e MSTP é praticamente obrigatório, pois sem ele a porta entra em Discarting durante o processo de Proposal/Agreement, causando intermitência na conexão. Uma interface com Porfast habilitado também não gera eventos TCN, nem limpa a tabela MAC por conta de mudança de topologia STP. Além da possibilidade de fazer a configuração por interface, podemos habilitar o Portfast globalmente como o comando spanning-tree portfast default (ou spanning-tree port type edge default, dependendo da plataforma). Em ambos os casos o comando é aplicado apenas às portas no modo acesso. Se o comando for habilitado no modo global e você quiser desativá-lo em uma interface específica, basta usar o comando spanning-tree portfast disable no modo interface. Portfast Trunk (port type edge trunk): Comando configurado por interface, com as mesmas características do comando anterior, mas diferente do que muitos podem imaginar, NÃO deve ser usado em interface trunk conectada a outro switch. O comando spanning-tree portfast trunk (ou spanning-tree port type edge trunk) deve ser usado para portas trunk que são conectadas à servidores, roteadores e outros equipamentos que suportam 802.1Q, mas NÃO à switches. BPDU Guard: Podemos habilitar o BPDU Guard (spanning-tree bpduguard enable) na interface ou globalmente (spanning-tree portfast bpduguard default). O BPDU Guard coloca a porta em Error Disable se ela receber BPDU. Quando usamos o comando no modo global o BPDU Guard é habilitado apenas nas interfaces configuradas com Portfast (Edge). Se o comando for habilitado globalmente e você precisar desativar em alguma interface, basta usar o comando spanning-tree bpduguard disable. Root Guard: Com o comando spanning-tree guard root (habilitado por interface), se a interface receber um BPDU superior, isto é, que indica um caminho melhor até o switch root, a interface é colocada em blocking (root inconsistent), e só voltará a funcionar normalmente quando parar de receber os BPDUs. BPDU Filter: O BPDU Filter tem a função de interromper a transmissão e recebimento de BPDUs. Quando habilitado globalmente com o comando spanning-tree portfast bpdufilter default, o comando é aplicado às interfaces configuradas com Portfast. Estas interfaces, quando conectadas, irão enviar 11 (1 imediatamente após ficar UP e outros 10, 1 a cada 2 segundos – Hello Timers) BPDUs. Se não receber nenhum BPDU a interface para de enviar BPDUs. No entanto a porta continua capaz de processar BPDUs, e se receber algum, o BPDU Filter é desconsiderado e a interface passa a agir normalmente de acordo com o STP. Para desativar o Filter em uma interface específica (depois de habilitado globalmente), usamos o comando spanning-tree portfast bpdufilter disable no modo interface. Assim como os outros comando, também podemos ativar o BPDU Filter por interface (spanning-tree portfast bpdufilter enable), porém, neste caso, a interface não enviará BPDUs e vai descartar os BPDUs recebidos. Esta opção é usada quando queremos que a interface não participe do STP. UDLD: O Unidirectional Link Detection é um mecanismo que permite o switch detectar se o par RX/TX está funcionando corretamente. Habilitamos a funcionalidade por interface, com o comando udld port, e caso seja detectado uma falha, a interface é colocada no modo Error Disable. Também podemos habilitar globalmente (udld enable) mas neste caso o comando será aplicado apenas às interfaces óticas (fibra). Em ambos os casos o UDLD deve ser habilitado nos dois dispositivos conectados. Loop Guard: A funcionalidade Loop Guard faz com que uma interface root ou alternate que pare de receber BPDUs seja colocada em loop inconsistent. Isso porque uma interface (root ou alternate) que estava recebendo BPDUs não deve parar de recebê-los durante o funcionamento normal da rede (pode indicar link unidirecional). Usamos o comando spanning-tree loopguard default (globalmente) para habilita a funcionalidade em todas as portas root e alternate, ou o comando spanning-tree guard loop no modo interface. Bridge Assurance: Funcionalidade aplicada somente ao RPVST+ e MST, em nem todos switches suportam. Com o Bridge Assurance o switch passa a enviar BPDUs em todas as portas ativas (incluindo portas backup e alternate) a cada 2 segundos (Hello Timer). Se uma interface não recebe o BPDU ela é colocada em Error Disable. Observe que neste caso as duas pontas precisam ter a funcionalidade habilitada, caso contrário o switch com Bridge Assurance vai desabilitar a porta por não receber BPDUs. Usamos o comando spanning-tree bridge assurance (no modo global) e spanning-tree portfast network (modo interface) para habilitar a funcionalidade. Importante dizer que apesar de alguns dos comandos acima basearem-se no Portfast quando habilitados no modo global, não há nenhuma relação entre eles. Isto é apenas uma forma lógica de escolher as interfaces que vão receber os comandos. Por exemplo, se habilitamos o BPDU Guard no modo global, o comando será aplicado apenas nas interfaces com Portfast. Isso porque, pela lógica, uma interface do tipo Edge é uma porta de acesso conectada a um endpoint, e não em um switch. Assim, se desejado, pode-se habilitar o BPDU Guard em uma interface mesmo sem habilitar o Portfast. Ainda existem outras opções (assim como mais detalhes das funcionalidades listadas acima), que podem ser vistas neste link: Optional STP Features Até a próxima.
Configurando Load Balancer no VMware NSX
Um dos serviços de rede que podemos virtualizar com o VMware NSX é o Load Balancer. Veja neste vídeo como criar e configurar um Edge Service Gateway para fazer o balanceamento de carga (HTTP) entre dois servidores virtuais. Topologia utilizada: Até a próxima.
