Minha jornada até o CCIE RS — Switching

Nesta série de artigos compartilharei minhas anotações acumuladas durante 3 anos de estudos até passar no lab de CCIE RS, anos atrás. São quase 400 páginas de cadernos com informações e observações que considerei importantes ao trabalhar com Routing and Switching por quase 15 anos. Algumas tecnologias nem são mais utilizadas, mas postarei da mesma forma :)

Eu acredito que estas informações possam ajudar não apenas a passar em certificações, mas no dia-a-dia de outras pessoas (como eu) ao lidar com infraestrutura Cisco.

Abaixo segue a primeira parte, sobre “Switching”, e ao final uma lista de comandos “show” + filtros que considero eficiente.

Fique a vontade para comentar e entrar em contato comigo no LinkedIn. Se gostou do conteúdo, incentivo a compartilhar com outros do ramo. Não se esqueça de seguir a mim e ao TechRebels clicando follow lá em cima :)

Core topics

• trunk
• vlans
• etherchannels
• 802.1q

L2 Ports

• access — uma vlan
• trunk — múltiplas vlans
• tunnel — VPN L2 transparente (QinQ)
• dynamic — negociação DTP

Negociation

DTP é habilitado por default (ISL -> Dot1q -> access).

DTP representa uma possível falha de segurança uma vez que devemos saber o destino de cada porta (trunk ou access).

Procure SEMPRE configurar a porta explicitamente como trunk ou access.

Trunking

ISL

• proprietário Cisco
• usa encapsulamento

802.1q

• open standard
• usa tag

DTP

• desirable — inicia negociação
• auto — escuta passivamente por negociação
• on — ajusta explicitamente para trunk e realiza negociação negociação DTP

OBS: TRUNK ON != TRUNK + DTP OFF (nonegotiate) -> desabilita um overhead de negociação de milissegundos, geralmente usado para aplicações com baixíssimo tempo de convergência.

Desabilitando DTP

• nonegotiate
• access
• dot1q-tunnel

Uma falha de convergência pode ocorrer caso configure em um lado “dynamic auto” e no outro “trunk + nonegotiate”. Neste caso um lado trunk habilitado enquanto do outro terá acesso e irá descartar os frames encapsulados, porém o switch que encaminha não sabe disso.

VTP

Permite centralizar a administração dos atributos das VLANs (somente a administração).

Simplifica a administração, mas não vale a pena pelos problemas que pode causar.

VTP por default usa domínio NULL e se receber um pacote com domínio em uma interface trunk herdará o novo domínio. Isso representa outra falha de segurança porque um SW não autorizado pode aprender sobre todas as VLANs na rede.

Autenticação é habilitada por default mesmo com a password não configurada. O que importa é o MD5.

O revision number altera cada vez que uma VLAN é adicionada ou deletada. Portanto, para forçar a sincronia podemos adicionar ou deletar VLANs ou derrubar o link.

Modos:

• server — cria ou deleta VLANs
• client — não cria ou deleta VLANs
• transparent — não altera a database, mas encaminha o update para demais trunks

VTP Pruning

Reduz replicação desnecessária de broadcasts, unknown unicasts e unknown multicasts (unknowns são encaminhados da mesma forma que broadcasts).

Peers perguntam aos vizinhos “quais VLANs vocês tem configuradas?” e “quais VLANs você está no caminho?”. Os vizinhos respondem as listas para as duas solicitações.

Prune eligible list — por default todas as VLANs padrão (2–1001) estão na eligible list. VLANs que não estão na eligible list NÃO podem ser prunadas. É exatamente o oposto da “trunk allowed list”.

VTP é proprietário e, portanto, em ambiente multivendor é recomendado modo transparent.

OBS: Se estiver usando Pruning e conectar um dispositivo que não suporta VTP através de um trunk, o switch não receberá request de pruning. Com isso o switch repassa no uplink que ele precisa de todas as VLANs e todos os switches neste caminho repassam a necessidade. Portanto qualquer equipamento que não suporta VTP e seja conectado através de um trunk estraga tudo que o VTP Pruning tenta otimizar. Para corrigir este cenário, limite as VLANs na trunk allowed list e o VTP assume que o resto pode ser “prunado”.

OBS: Qualquer equipamento no mesmo domínio e com um número de revisão mais alto, quando conectado ao domínio irá modificar a database dos outros SWs (ataque simples).

Modo Transparent (na teoria):

• Versão 1 — encaminha pacotes VTP do mesmo domínio
• Versão 2 — encaminha todas as versões e domínios de VTP (não se importa)

OBS: na prática o modo transparent não encaminha pacotes de domínios diferentes além do DTP ainda bloquear o trunk.

Não é possível utilizar o modo transparent em uma topologia com pruning porque o SW transparent encaminhará as mensagens de pruning nos demais trunks e os neighbors irão prunar tais VLANs nestes trunks, interrompendo a comunicação nelas.

VTPv3

Corrige problema de segurança relacionado a sobrescrever o número de revisão através do uso de primary/secondary servers. Para realizar qualquer alteração primeiro precisa promover o SW para “primary” (evitando acidentes). Isto separa a função de “server” e “atualizador temporário”.

“New advertisements” tornam a administração mais fácil:

• extended vlans
• private vlans
• MST config
• hidden password
• VTPv3 pode ser habilitado globalmente ou por interface.
• Função de “secondary server” e “cliente” é essencialmente a mesma na prática porque não pode alterar vlans.
• VTPv3 pode habilitar pruning globalmente na topologia

#vtp primary-server [vlan|mst] — Usa modo exec para promover SW para primary no modo “vlan” (normal) ou “mst” permitindo topologias lógicas diferentes. EX: SW pode ser server para “vlan” e client para “mst”.

#show vtp status — Mostra as features para “vlan” e “mst”. Se “primary ID” é 0000.0000.0000, não existe primary server na rede.

https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/solution_guide_c78_508010.html

Extended VLANs

• 1006–4094
• Requerem VTP transparent, portanto não permitem pruning
• Funciona com VTPv3, mas a maioria dos equipamentos não suporta
• Portanto VLANs estendidas devem ser especificadas em cada SW

L3 Routing

• Switched Virtual Interface (SVI)
• Native Routed Interface

SVI mostra “protocol down” quando não há uma instância de STP para a VLAN.

Quando não possui “default gateway” configurado, o SW manda ARP para tudo. Se algum router nas VLANs estiver usando proxy-arp pode confundir o comportamento e testes porque responde com seu próprio ARP. Ficar atendo com MACs repetidos.

A escolha entre SVI e Native L3 depende basicamente da topologia. Além do que interfaces nativas L3 convergem mais rápido porque não precisam esperar o STP convergir primeiro.

Router-on-a-Stick

• Versão antiga da SVI
• Roteadores não suportam DTP ou VTP
• Roteadores encapsulam pacotes através de sub-interfaces
• VLAN nativa deve ser especificada na interface (ou sub-interface) ou usar tag

Etherchannel

• Usado para agregar banda de links físicos
• Utiliza mesma lógica de PPP Multilink
• Pode ser qualquer tipo de interface (L2, L3, Trunk, Tunnel)

OBS: Etherchannel é o nome patenteado da Cisco para “NIC teaming”. Nic teaming é a agregação de portas de acesso para servidores (L2).

Modos de Etherchannel

• on — sem negociação
• PAgP — desirable ou auto
• LACP — active ou passive

Novamente, a vantagem de não usar negociação é convergir mais rápido. A desvantagem é não prevenir contra falhas de configuração.

Load balance

• source and destination MAC
• source and destination IP

Se uma interface está sendo muito mais utilizada do que as outras, obviamente é porque o load balance não está adequado.

Interfaces membras do channel precisam ter a mesma configuração principal.

Sempre configure o channel com as interfaces DOWN para evitar falhas na negociação que podem gerar loops L2.

Não tem como saber qual o caminho L1 o fluxo está percorrendo no channel porque todos os MACs e o STP apontam para o channel. O que conseguimos verificar é a utilização dos links.

OBS: Ao realizar alterações em um channel, altere a interface lógica e as interfaces membras todas ao mesmo tempo usando “range”.

OBS: Quando o channel é criado, ele herda o “tipo de interface” das interfaces membras (L2, L3, Trunk ou Tunnel). Se mudar o tipo de interface (ex: L2-> L3) sem mudar o channel, elas são retiradas do bundle (…e tá feita a cagada). Portanto SEMPRE especifique o tipo de interface corretamente antes de adicionar ao channel.

802.1q Tunneling

Criado para oferecer serviço VPN over Ethernet, geralmente utilizado em ambientes Metro Ethernet. É uma versão “light” de MPLS VPN.

PE adiciona um tag 802.1q adicional para todos os frames recebidos do CE, chamado “metro tag” ou “QinQ”. Portanto para o SP cada cliente estará dentro de uma única VLAN e não permite que as VLANs se comuniquem porque cada uma tem sua própria MAC table.

Obviamente todos os links para o CE devem ser configurados manualmente e todos os SWs do ISP devem conhecer a VLAN.

Principal problema dessa solução é não ser escalável porque a rede fim-a-fim toda do ISP precisa ser L2 trunking.

• OBS: MPLS é “over IP” e portanto é escalável.

Segundo principal problema é que por ser L2, os SWs do ISP precisam conhecer os MACs de todos os end-hosts de todos os clientes. Obviamente isto também não escala.

Apenas os links para os CEs precisam ser Dot1q. Internamente a rede do ISP pode ser do1q ou ISL desde que seja L2 trunking fim-a-fim.

Terceiro principal problema é que usam TAG L2 de 4 bytes. Portanto se a MTU interna do ISP é de 1500 bytes, a MTU do cliente deve ser 1496 bytes. Como ethernet não suporta fragmentação, se o cliente encaminhar frames com MTU padrão (1500 bytes), eles serão descartados.

• OBS: Para cada “QinQ” são descartados 4 bytes de overhead.
• OBS: Novamente, MPLS resolve este cenário porque utiliza pacotes IP, que podem ser fragmentados.

SWs utilizando “QinQ” descartam pacotes de control plane dos CEs (CDP, VTP, STP, etc) porque eles usam MACs especiais que não são permitidos.

L2 Protocol Tunneling

Utilizado tipicamente para resolver a questão acima com “QinQ”, codificando os protocolos de control plane dentro de um MAC específico.

Protocolo proprietário Cisco.

Geralmente não há motivos para usar isso sem “QinQ” mas tecnicamente podemos fazer um tunnel L2 de protocolos tornando os SWs no caminho transparentes.

QinQ não funciona legal caso a VLAN de acesso para algum cliente seja a mesma VLAN nativa de um trunk. O resultado é que o switch não adiciona o TAG e vaza o pacote do cliente (com as TAGs de VLAN) na rede interna do SP. Então as VLANs internas do cliente vazam para as VLANs de acesso dos outros clientes (com respectivos números). Solução para isso é habilitar TAG de vlan nativa no ISP.

L2 protocol tunneling permite tunnelar etherchannels. Usado geralmente quando se precisa de mais banda do que o ISP oferece com 1 interface. O channel deve ser específico fim-a-fim, do contrário causa loop L2 e portanto precisa de uma VLAN separada para cada interface fim-a-fim membra do channel.

Spanning-tree

1. Eleger root bridge
2. Eleger root port em cada SW
3. Eleger portas designadas em cada SW

Eleição da Root Bridge se baseia na melhor Bridge Identifier

• Bridge priority 0–61440 (incrementos de 4096)
• System ID extension 0–4095 (número da VLAN)
• — A priority funcional é a soma da priority configurada + sys-id-ext.
• MAC address
• OBS: Se utilizar prioridade padrão na rede, SWs mais antigos tendem a se tornar root por terem MAC mais antigo.

Eleição da Root Port:

1. Menor custo até o root
2. Menor BID
3. Menor Port ID

Eleição da Designated Port:

1. Menor custo até o root
2. Menor BID
3. Menor Port ID

Todas as outras portas entram em blocking (BLK) mode.

• Recebem BPDU
• Descartam tráfego
• Não podem enviar tráfego

OBS: Fora a eleição do Root, quase todo o resto pode ser ajustado através do custo.

OBS: É através do sys-id-ext que o SW identifica a VLAN de uma BPDU.

STP Timers

Hello

• Frequência de envio de BPDUs
• Default 2 seg

MaxAge

• Tempo máximo de espera entre BPDUs
• Default 20 seg

Forward Delay

• Tempo utilizado nos estados de listening e learning
• Default 15 seg

Timers são ajustados pela Root bridge

• No modo PVST somente a Root gera BPDUs

Tempo de convergência default é 50 seg (20s + 15s +15s).

Advanced STP Features

Portfast

• Edge ports não esperam o forward delay
• Não geram TCN quando mudam estado
• Portfast não desabilita o STP na interface

TCNs informam os SWs para realizarem um flush da cam table baixando o aging time (default 300 seg) para o valor do MaxAge (default 20 seg).

• OBS: Usar edge ports sem port-fast ou edgeport em redes L2 grandes é muito ineficiente.

É possível habilitar portfast em trunks, mas mesmo com o comando global, ele permanece desabilitado em trunks por default.

Cenário típico onde um edge port precisa de trunk é quando há um servidor com suporte a diferentes VLANs.

Uplink Fast

Falhas diretas na root port devem reconvergir imediatamente se ports alternativas (ALT) estiverem disponíveis.

A porta ALT imediatamente transiciona para FWD porque já pré-calculou um caminho livre de loop.

Imediatamente aumenta a prioridade do SW evitando estar no caminho de trânsito entre outros SWs e a Root bridge. Também aumenta o custo das interfaces.

O SW também realiza spoofing da sua CAM table através do ALT link para que os SWs vizinhos atualizem a CAM table sobre as sources que o SW conhece.

O SW forma um grupo de possíveis caminhos para o root e quando a root port cai, automaticamente comuta o tráfego para a próxima porta do grupo.

Backbone Fast

Permite detectar falhas indiretas e recalcular imediatamente. Ao receber BPDUs inferiores, o SW ignora o MaxAge e imediatamente recalcula o caminho.

É necessário configurar em todos os SWs porque é essencialmente um parâmetro de negociação entre os SWs.

Não é tão rápido quanto o Uplink Fast porque precisa recalcular o caminho. Mesmo com os timers reajustados, a convergência leva em torno de 8 seg (já é muito).

BPDU Filter

• Filtra BPDU in e out
• Geralmente implementado na camada de acesso, evita informar qualquer informação sobre a root bridge que possa ajudar em um potencial ataque (MAC, priority, etc)
• Funciona como “passive interface” para o STP

OBS: Quando configurado na interface, filtra in e out. Quando configurado no modo global junto com portfast, opera somente como “outbound filter” porque o “portfast” permanece monitorando a entrada de BPDUs para desabilitar o portfast caso receba alguma BPDU e desabilita o BPDU filter. BPDU filter e portfast habilitados globalmente representam uma falha de segurança porque força a ativação do STP ao receber uma BPDU criando oportunidade para um “man in the middle attack”.

BPDU Guard

Desabilita a interface caso uma BPDU seja recebida colocando a interface em err-disable.

Implementar BPDU Guard junto com portfast globalmente é uma forma mais segura porque toda interface “não trunk” habilita o portfast e entra em err-disable se receber BPDU.

Root Guard

Desabilita a interface se uma BPDU superior for recebida. Mais precisamente desabilita a instância do STP para esta interface (root inconsistent state).

Deve ser implementado em todas as interfaces downstream L2 em direção a camada de acesso.

Loop Guard e UDLD

Loop guard é uma feature do STP e UDLD é uma feature a parte, mas essencialmente tem a mesma função. O problema ocorre quando uma interface envia BPDUs mas a outra não recebe, o MAxAge expira e ambas as interfaces entram em “designated state”… cagada tá feita!

Principais diferenças:

• Loop Guard usa BPDU e UDLD usa keepalive próprio.
• Loop Guard protege contra falhas de software do STP, UDLD não.
• UDLD protege contra erros de conexão de cabeamento, Loop Guard não.
• Portanto é recomendável utilizar as duas features juntas, principalmente em um ambiente de fibra.

MST (802.1s)

MST usa conceito de instâncias, com cada instância agrupando determinadas VLANs em uma topologia lógica.

SWs com mesmas instâncias, número de revisão e nome formam uma Região.

Diferentes regiões se enxergam como “Virtual Bridges”, escondendo informações sobre comunicação e falhas internas de uma região. Portanto, falhas em uma região não afetam todas as outras regiões da rede (conceito de “caixa preta”).

Usa mesmo processo de eleição que CST/PVST:

Root bridge

• 1- Menor BID

Root port

• 1- Menor custo até o root
• 2- Menor BID upstream
• 3- Menor Port ID

Região é determinada por:

• Instância
• VLANs configuradas
• Número de revisão
• Nome

Quando um link trunk é habilitado no MST, ele começa a operar rapidamente sem esperar intervalo “MaxAge + Listening + Learning”. Isso porque o MST habilita Rapid-PVST por instância e o RPVST usa negocição “request and response” (muito mais rápida).

MST0 representa o “Common Internal Spanning Tree” ou CIST. MST0 (CIST) é usado para realizar interoperabilidade entre as regiões e PVST.

MST é “backwards compatible” com CST (802.1d) e PVST+, através de replicação das informações de todas as VLANs na MST0. A principal implicação disso é que o Root da CST PRECISA estar dentro do domínio MST. Nesse caso, cada região é vista como um SW, independente de quantos SW tiver.

Timers do MST são os mesmos do PVST, mas são utilizados somente entre SWs que não falam Rapid-PVST.

OBS: Qualquer VLAN criada e não associada explicitamente com nenhuma instância é automaticamente associada a MST0.

Rapid-PVST

Usa sistema de negociação “proposal and response”. O Root Bridge propõe aos SWs downstream que coloquem suas interfaces como Root Port (com confirmando através de ACK), bloqueando suas outras interfaces (BLK) e iniciando o mesmo sistema de negociação com os próximos SW downstream.

• OBS: Este sistema de negociação só ocorre entre links P2P (full-duplex) e non-edge. Nas demais portas retorna para modo PVST.

OBS: “PVST portfast” é similar a “Rapid-PVST edgeport”.

Relação entre MST e Rapid-PVST

MST utiliza sistema de negociação do RPVST enquanto mantêm uma instância por grupo, porém todos os SWs da região precisam concordar com a config.

O RPVST pode ser configurado independente em cada SW (não precisa ser tudo de uma vez), porém habilita 1 instância por VLAN gerando mais overhead.

Flex Links

Permite redundância de links sem usar STP, desabilitando STP nas interfaces primária e backup.

Realiza spoofing de MAC address através dos links de backup para permitir que os SWs vizinhos atualizem suas CAM tables (Mac-address Move Update — MMU).

Notas gerais de Switching

• Quando atrelamos estaticamente uma interface de acesso a uma VLAN inexistente, essa VLAN é automaticamente criada. Porém quando um TRUNK é configurado com uma VLAN inexistente, essa VLAN não é criada e nenhum aviso é gerado.
• O tempo de recuperação de ERR-DISABLE é global para qualquer condição de ERR-DISABLE, porque é um estado global.
• Ao retirar a VLAN 1 de um trunk, o envio de pacotes de controle na VLAN 1 entre SWs não é interrompido (pode ser visto através de network analyzer). Porém, nenhum dado será encaminhado e STP não ocorrerá sobre este enlace. É uma técnica utilizada para quebrar a VLAN 1 em domínios menores.
• Port-priority geralmente é configurado nas interfaces designadas partindo da Root bridge em direção aos SWs de acesso.
• Port-cost geralmente é configurado nas root ports e alt ports em direção a Root Bridge.

Transparent Bridging

Por padrão:

• Roteadores roteiam IP
• Switches comutam IP
• Roteadores não podem fazer “routing” E “switching”

Transparent bridging sujeita o router às mesmas condições do STP:

• Somente 1 caminho ativo.
• Eleição de:
• - Root bridge
• - Root port
• - Designated port

Processo:

1. Desabilitar roteamento
2. Criar bridge group para STP

• bridge X protocol ieee (X = vlan)

3. Aplicar grupo a interface

• bridge-group X

4. Se aplicar a interface multipoint NBMA, precisa mapear a bridge

• ex: frelay map bridge

Objetivo é estender o domínio de broadcast através de roteadores. Basicamente cria uma instância STP regular (802.1d) e junta as interfaces no mesmo grupo.

OBS: para confirmar se dispositivos estão no mesmo domínio de broadcast -> “ping 255.255.255.255”.

Integrated Routing & Bridging (IRB)

Evolução de uma feature antiga chamada “Concurrent Routing and Bridging” que permitia que o router realizasse routing e bridging da mesma stack (pilha) de protocolos, desde que não fosse na mesma interface.

Não há comunicação entre os 2 domínios.

IRB usa Bridge Virtual Interface para conectar o domínio comutado com o domínio roteado. Usa o mesmo princípio da SVI em switches. Atualmente não é uma boa solução.

OBS: Parâmetros “bridge” e “route” só aparecem quando IRB é habilitado.

OBS: Muito cuidado quando mexer com Transparent Bridging ou IRB porque ao habilitar “bridging”, os pacotes não serão mais roteados.

• bridge irb
• bridge X route ip
• bridge X bridge ip

BVI é o mesmo que SVI. Em domínio comutado, é na BVI que se configura opções L3 (NAT, QoS, etc).

Fallback Bridging

• SW 3560 por default só roteia IPV4 e IPV6
• Todos os outros protocolos devem ser comutados
• Permite outras stacks serem comutadas entre SVI e interface roteada
• SW sem roteamento habilitado responde pings de suas interfaces, mas não encaminha pacotes (não roteia) por estas interfaces

Comandos “Show “ para Switching

sh int status | ex not

show int X/X switchport — verifica que interface está operando em routed mode, como uma porta layer 3

sh vlan

sh vlan | in active

sh span vlan X

sh int trunk — O 4 campos são importantes. “n-xxx” significa negociated

sh int trunk | in tru

sh span

sh span sum

sh span det

sh span int X/X

sh vtp status

sh vtp devices — para vtp3

sh vtp pass

sh ether

sh ether sum

sh ether prot

sh ether X port

sh ether det

sh ether det | in Mode

sh ip int bri | ex un

sh span | in VLAN|root

sh span | in VLAN|Fa

sh span | in VLAN|FWD|Cost

sh span int XX det

sh span sum

debug span events

sh err det

sh err rec

sh udld fa x/x

sh udld nei

sh span sum

sh span mst config

sh span mst

sh storm

sh storm uni

sh monitor

sh moni det

sh moni session x

sh moni se x det

sh vlan private

sh int pri map

sh bridge X — similar a “sh mac address-table”

sh bridge X group — interfaces que fazem parte do grupo STP

sh span X — mostra STP

O que achou do conteúdo?

Faltou algum ponto importante?

Fala pra mim nos comentários.

Se gostou do conteúdo, incentivo a compartilhar com outros do ramo. Não se esqueça de seguir a mim e ao TechRebels clicando follow aí embaixo :)

Sobre o autor:

Giuliano Barros é Network Consultant & Founder da Control Plane — Network Services.

Graduado em Ciência da Computação, certificado CCIE RS pela Cisco Systems e trabalha há 15 anos em projetos para médias e grandes empresas. linkedin.com/in/giulianobarros