Bacharelado em Informática. Internet e Arquitetura TCP/IP. Evolução. Evolução. Disciplina: Internet e Arquitetura TCP/IP. Switches

Transcrição

1 Bacharelado em Informática Disciplina: Internet e Arquitetura TCP/IP Switches Evolução Prof. Sérgio Colcher colcher@inf.puc-rio.br Copyright by TeleMídia Lab. 1 2 Evolução Hubs Switches de Nível 1: Hubs que Aprendem Switches de Nível 2 Switches de Nível 3 Switches Multi-camandas Evolução Hubs Repetidores Multiporta Switches de Nível 1: Hubs que Aprendem Aprendizado idêntico ao das pontes Porém Não são store-and-forward Não processam spanning-tree Problema: repetidor encaminha antes da decisão de porta ser tomada Parar no meio não é uma boa opção Daria a impressão de que a rede está vazia Outra estação poderia começar a transmitir causando colisão com uma transmissão já em curso Sinaliza colisão nas portas em que não deveria ter encaminhado os dados 3 4

2 Repetidores Repetidores Não pode haver um caminho fechado de repetidores Gera tráfego extra inútil quando o pacote não é inter-rede Ethernet Ethernet 5 6 Evolução Hubs Repetidores Multiporta Switches de Nível 1: Hubs que Aprendem Switches de Nível 2 Full-Duplex VLANs Spanning Tree Pontes Ethernet Token Ring 7 8

3 Aplicação Apresentação Sessão Transporte Rede Enlace 1 Físico 1 Pontes Aplicação Apresentação Sessão Transporte Rede Enlace 1 Enlace 2 Enlace 2 Físico 1 Físico 2 Físico 2 Radia Perlman: I never know what to say when someone comments that switches have replaced bridges and routers. Switches A switch is just a generic term that has come to mean a box that moves data quickly. Some of them (layer 2 switches) are bridges. Others (layer 3 switches) are routers Switches Domínios de Difusão (Broadcast) Domínio Broadcast Domínio de Colisão Domínio de Colisão Nível 1 Nível 1 Nível 2 Switch A É vantajoso separar as LANs em domínios de difusão Em alguns casos, tráfego broadcast cresce proporcionalmente ao número de estações ARP é um exemplo de vilão de muitas redes interligadas por pontes Domínio de Colisão Nível 1 Segurança Domínio de Colisão Nível 1 Nível 2 Switch B 11 12

4 VLAN VLANs VLAN A VLAN B VLAN VLAN Switch VLAN A VLAN B VLAN A VLAN B Roteador 15 16

5 IEEE 802.1Q Redes Virtuais IEEE 802.1Q Permite a implementação de VLANs independente dos fabricantes de equipamentos: Enlace de trunk entre os switches, que multiplexa os quadros das 3 VLANs VLAN A VLAN B VLAN C 7B 6B 6B 2B 2B 2B 46 a 1500B Start Frame Destination Source Preamble TPID TCI LengthData + PAD Delimiter MAC Address MAC Address TPID: Tag Protocol Identifier. 2B CRC TCI: Tag Control Information: 3 bits com informações de prioridade 12 bits com o identificador de VLAN (VID) VLAN A VLAN B VLAN C 4096 VLANs são possíveis Protocolos para Enlaces de Trunk Trunking with ISL Há, na verdade, duas formas de frame tagging 1. Cisco proprietary Inter- Switch Link (ISL) e 2. IEEE 802.1Q. VLAN A VLAN B VLAN C Atualmente, a própria Cisco recomenda o uso do 802.1Q. IEEE 802.1Q ou ISL Propietário Cisco Encapsula o quadro Não modifica o quadro original VLAN A VLAN B VLAN C

6 Trunking with 802.1Q Comparando ISL e 802.1Q ISL 802.1Q Proprietário Não Proprietário Padrão IEEE Adiciona tag de 4 bytes ao quadro original Encapsulado Independente de Protocolo Encapsula Frame em um novo frame Rotulado Dependente de Protocolo Adiciona um campo ao cabeçalho do Frame ISL (Inter-Switch Link) não é mais suportado pela Cisco, que passou a adotar o Q. Note: nem todos os switches suportam os dois protocolos. 22 VLANs and trunking. Criando VLANs Non-Trunk Links Trunk Link Default vlan 1 vlan 10 Default vlan 1 Non-Trunk Links Enlaces de Trunk não pertencem a uma VLAN específica Servem como conduite entre Switches. Exemplo: Associar portas a uma VLAN (Cisco IOS) Switch(config)#interface fastethernet 0/9 Switch(config-if)#switchport access vlan 10 Switch(config-if)#switchport mode access access informa que a porta será utilizada como acesso e não como trunk

7 Configurando VLANs Configurando VLANs vlan 2 Switch(config)#interface fastethernet 0/5 Switch(config-if)#switchport access vlan 2 Switch(config-if)#switchport mode access Switch(config-if)#exit Switch(config)#interface fastethernet 0/6 Switch(config-if)#switchport access vlan 2 Switch(config-if)#switchport mode access Switch(config-if)#exit Switch(config)#interface fastethernet 0/7 Switch(config-if)#switchport access vlan 2 Switch(config-if)#switchport mode access vlan 2 Switch(config)#interface fastethernet 0/5-7 Switch(config-if)#switchport access vlan 2 Switch(config-if)#switchport mode access Switch(config-if)#exit Não funciona em todos os modelos de switch. A sintaxe do comando pode variar VLANS Estáticas Default VLAN 1 Default VLAN 1 VLAN 10 Configured Switch(config)#interface fastethernet 0/9 Switch(config-if)#switchport access vlan 10 VLANs Estáticas são chamadas port-based ou port-centric. Trata-se do método mais comum de associação de VLANs Quando um disposotivo é conectado a uma porta, ele automaticamente passa a pertencer a VLAN configurada naquela porta. Normalmente existe uma VLAN default Em equipamentos Cisco é a VLAN 1. Dynamic Membership VLAN operation Dynamic membership VLANs são criadas por intermédio de ferramentas de gerência São bem menos comuns que as VLANs estáticas VLANs dinâmicas permitem a associação da estação a uma VLAN baseada no Endereço MAC da estação conectada a uma porta. Quando um dispositivo entra na rede, é realizada uma consulta em uma base de dados associada ao switch para determinar a VLAN correta

8 Default: dynamic desirable Criando VLANs By default, all ports are configured as This link will become a trunking link unless one of the ports is configured with as an access link, I.e. switchport mode access switchport mode dynamic desirable, which means that if the port is connected to another switch with an port configured with the same default mode (or desirable or auto), this link will become a trunking link. Evolução Hubs Repetidores Multiporta Switches de Nível 1: Hubs que Aprendem Switches de Nível 2 Full-Duplex VLANs Spanning Tree Spanning Tree Criada para resolver o problema de ciclos em redes com pontes transparentes Pontes Transparentes Desenvolvida originalmente pela Digital Equipment Corporation e adotado pelo comitê Transparência: LANs não são modificadas ao serem interconectadas por esse tipo de ponte Operam em modo promíscuo Tabela de rotas atualizada dinamicamente começa vazia e é preenchida à medida que chegam os quadros (learning bridges) entradas na tabela são atualizadas com anotação da hora periodicamente, processo limpa entradas não utilizadas há algum tempo 31 32

9 Pontes Transparentes Pontes Transparentes - Exemplo Recebeu quadro sem erro na porta X Retransmissão SIM ED encontrado na tabela? SIM Porta de saída = X? NÃO NÃO Retransmite pacote na porta de saída adequada Retransmite pacote em todas as portas exceto a porta X porta1 porta2 porta1 B 2 porta2 LAN 1 LAN 2 LAN 3 A B C D E F EO encontrado na tabela? NÃO Aprendizado SIM atualiza porta X e tempo na tabela Inclui EO, porta X e o tempo na tabela B 2 FIM Pontes Transparentes - Exemplo Pontes Transparentes - Exemplo porta1 porta2 porta1 B 2 porta2 porta1 porta2 porta1 B 2 porta2 E A E A LAN 1 LAN 2 LAN 3 A B C D E F LAN 1 LAN 2 LAN 3 A B C D E F ED EO E A Dados A 1 Estação Porta ED EO E A Dados A 1 A 1 B 2 B

10 Pontes Transparentes - Exemplo Pontes Transparentes - Exemplo porta1 porta2 porta1 B 2 porta2 porta1 porta2 porta1 B 2 porta2 E A LAN 1 LAN 2 LAN 3 A B C D E F LAN 1 LAN 2 LAN 3 E A A B C D E F ED EO E A Dados A 1 A 1 ED EO E A Dados A 1 A 1 B 2 B Pontes Transparentes - Exemplo Pontes Transparentes - Exemplo porta1 porta2 porta1 B 2 porta2 porta1 porta2 porta1 B 2 porta2 A B LAN 1 LAN 2 LAN 3 A B C D E F A B LAN 1 LAN 2 LAN 3 A B C D E F ED EO A B Dados A 1 A 1 ED EO A B Dados A 1 A 1 B 2 B

11 Pontes Transparentes - Exemplo Pontes Transparentes - Exemplo porta1 porta2 porta1 B 2 porta2 porta1 porta2 porta1 B 2 porta2 F E F E LAN 1 LAN 2 LAN 3 LAN 1 LAN 2 LAN 3 A B C D E F A B C D E F F E ED EO F E Dados A 1 A 1 E 2 ED EO F E Dados A 1 E 2 A 1 E 2 B 2 B Pontes Transparentes - Exemplo Pontes Transparentes - Exemplo porta1 porta2 porta1 B 2 porta2 porta1 porta2 porta1 B 2 porta2 F E D C LAN 1 LAN 2 LAN 3 LAN 1 LAN 2 LAN 3 A B C D E F F E A B C D E F ED EO F E Dados A 1 E 2 A 1 E 2 ED EO D C Dados A 1 E 2 C 2 A 1 E 2 C 1 B 2 B

12 Pontes Transparentes - Exemplo D C porta1 porta2 porta1 B 2 porta2 LAN 1 LAN 2 LAN 3 A B C D D C E F ED EO D C Dados A 1 E 2 C 2 D C A 1 E 2 C 1 Problema: Pontes Transparentes Quando a conexão das LANs através de pontes forma um caminho fechado A B C D * A Q 1 E F G H B Problema: Pontes Transparentes Quando a conexão das LANs através de pontes forma um caminho fechado Problema: Pontes Transparentes Quando a conexão das LANs através de pontes forma um caminho fechado A B C D A B C D Q 1 * A * A Q 1 * A Q 1 E F G H E F G H Q 2 * A 47 48

13 Problema: Pontes Transparentes Quando a conexão das LANs através de pontes forma um caminho fechado Problema: Pontes Transparentes Quando a conexão das LANs através de pontes forma um caminho fechado A B C D A B C D * A Q 1 * A Q 2 * A Q 2 E F G H E F G H * A Q Problema: Pontes Transparentes Quando a conexão das LANs através de pontes forma um caminho fechado Problema: Pontes Transparentes Quando a conexão das LANs através de pontes forma um caminho fechado A B C D A B C D * A Q 4 Q 3 * A * A Q 2 E F G H Q 3 * A E F G H 51 52

14 Spanning Tree Problema: Pontes Transparentes Quando a conexão das LANs através de pontes forma um caminho fechado Solução: Computar caminho único entre cada par de LANs SPANNING TREE Teoria Spanning Tree Para todo grafo conexo, consistindo de nós e arcos conectando pares de nós (as LANs são os nós, e as pontes, os arcos do grafo), existe uma árvore geradora (spanning tree) de arcos que mantém a conectividade do grafo sem conter caminhos fechados Spanning Tree Protocol (STP) STP often accounts for more than 50% of the configuration, troubleshooting, and maintenance headaches in real-world campus networks (especially if they are poorly designed). It is a complex protocol that is generally poorly understood. Radia Perlman Idealizadora do STP 55 56

15 Árvore Geradora e o Padrão IEEE 802.1D O propósito do algoritmo de árvore geradora é fazer com que as pontes descubram, dinamicamente, um subconjunto da topologia física que seja livre de ciclos (uma árvore), que ainda permita atingir todas as redes e suas respectivas máquinas. Árvore de Cobertura ou Árvore Geradora Árvore Geradora e o Padrão IEEE 802.1D A idéia básica do algoritmo da árvore geradora é a de fazer com que as pontes se comuniquem entre si propagando informações que permitam calcular e manter a árvore de cobertura. trocadas em quadros especiais, denominados pelo padrão IEEE 802.1D de Configuration Bridge Protocol Data Units (ou Configuration BPDUs). Por simplicidade, chamaremos essas mensagens apenas de mensagens de configuração Identificação das Pontes e suas Portas Cada ponte, segundo o IEEE 802.1D, tem um identificador único denominado Bridge ID ou BID 8 bytes Identificação das Pontes (Bridge Id BID) Versões anteriores à Revisão de 1998 Bridge Priority Versões posteriores à Revisão de bytes 6 bytes System Identifier Cada ponte, segundo o IEEE 802.1D, tem também um um identificador para cada uma de suas portas, denominado Port Id. 2 bytes 59 Bridge ExtededSystem Priority Id 4 bits 12 bits System Id = MAC Address 802.1D antes de 1998 Uma Spanning Tree para Todas as VLANs 802.1D Após 1998 Várias SPTs, uma para cada VLAN BID deve diferenciar VLAN Extended System ID carrega VLAN ID System Identifier

16 Árvore Geradora e o Padrão IEEE 802.1D Em linhas gerais, para construir a árvore de cobertura, cada ponte transmite periodicamente uma mensagem contendo sua identificação. Um algoritmo distribuído seleciona a ponte que vai ser a raiz da árvore (por exemplo, no caso do padrão, a que possui o menor identificador). Uma vez determinada a raiz, a árvore é construída com cada ponte determinando o seu menor caminho (menor custo) para a raiz. Mensagens de Configuração do IEEE 802.1D Mensagens de configuração contêm as informações necessárias para que as pontes possam: eleger uma única, dentre todas as pontes em todas as redes interligadas, para ser a ponte raiz da árvore; calcular o caminho mínimo, dentre todos os caminhos possíveis, que existe entre elas e a ponte raiz; para cada segemento de rede, eleger uma ponte designada daquela rede, que representa a ponte mais próxima da ponte raiz escolher uma porta, denominada porta raiz, que oferece o melhor caminho entre elas e a ponte raiz; selecionar as portas incluídas na árvore de cobertura Mensagens de Configuração do IEEE 802.1D Mensagens de configuração enviadas por uma ponte em uma de suas porta são recebidas por todas as outras pontes que residem no segmento de rede ao qual essa porta está conectada. pontes utilizam, como endereço de destino das BPDUs de configuração, um endereço de multicast especial Denominado Bridge Group Address. Mensagens de Configuração do IEEE 802.1D O corpo das mensagens de configuração contém, entre outras coisas, as seguintes informações: Root ID: o identificador que a ponte transmissora da mensagem assume ser da ponte raiz. Root Path Cost: o custo daquele que é considerado o menor caminho entre a ponte transmissora da mensagem e a ponte raiz naquele momento Bridge ID: o identificador da ponte transmissora da mensagem. Port ID: o identificador (numérico) da porta utilizada pela ponte transmissora para enviar a mensagem de configuração. BPDU de Configuração Protocol ID (2 Bytes) Version (1 Byte) Message Type (1 Byte) Flags (1 Byte) Root ID (8 Bytes) Root Path Cost (4 Bytes) Bridge ID (8 Bytes) Port ID (2 Bytes) Message Age (2 Bytes) Max Age (2 Bytes) Hello Time (2 Bytes) Forward Delay (2 Bytes) 63 64

17 Spanning Tree Denominamos vetor de prioridade a seqüência formada pelas quatro informações anteriores mais a Port Id Rec (porta pela qual a BPDU chega) <Root ID>. <Root Path Cost>. <BID>. <Port ID>. <Port ID Rec> Cada ponte assume, inicialmente, que ela própria é a ponte raiz Transmite mensagens de configuração em cada uma de suas portas com Root ID igual ao seu próprio identificador, informando um custo igual a zero. Cada ponte, ao receber mensagens de configuração, guarda o melhor vetor de prioridade recebido em cada porta Spanning Tree A escolha do melhor vetor de prioridade em cada porta é feita considerando todas as mensagens recebidas naquela porta e as mensagens que a própria ponte envia por essa porta. Para a eleição do melhor, dados dois vetores C1 e C2, utiliza-se o critério C1 é melhor do que C2 se C1 < C2 A comparação < é realizada da esquerda para direita Ex: < < Spanning Tree 67 O critério para a eleição do melhor,vetor dados dois vetores C1 e C2 que foi descrito anteriormente corresponde a aplicar os seguintes critérios, em ordem: 1. C1 é melhor do que C2 se o Root ID contido em C1 é numericamente inferior ao Root ID contido em C2. 2. Se os Root IDs contidos em C1 e C2 são iguais (empate no critério 1), então C1 é melhor do que C2 se o custo contido em C1 é menor do que o custo contido em C2. 3. Se os custos e os Root IDs contidos em C1 e C2 são iguais (empate nos critérios 1 e 2), então C1 é melhor do que C2 se o Bridge ID de C1 é numericamente inferior ao de C2. 4. Se houve empate nos critérios 1, 2 e 3, então C1 é melhor do que C2 se o Port ID contido em C1 é menor do que aquele contido em C2. 5. Se houve empate nos critérios 1, 2, 3 e 4, então C1 é melhor do que C2 se o Port ID rec contido em C1 é menor do que aquele contido em C2. Cálculo do Root ID e do Custo para a Raiz 68 A partir das mensagens de configuração recebidas em todas as interfaces (portas), cada ponte decide, de forma independente das demais, quem é a ponte raiz, da seguinte forma: A identidade da ponte raiz é o menor valor de Root ID de todos os vetores de todas as portas.

18 Exemplo Assuma, por exemplo, uma ponte B com 4 portas e que tem identificador igual a 15. Suponha que os vetores armazenados em cada uma de suas portas são os seguintes: Root ID Custo Bridge ID Porta Porta Porta Porta Exemplo Após a seleção da ponte raiz, cada ponte calcula sua distância até ela. Se ela própria é a raiz, então essa distância (custo) é zero. Caso contrário, a ponte usa os valores armazenados em cada porta sobre o custo que as outras pontes (vizinhas) informaram como sendo o custo de chegarem à raiz. A ponte soma o seu custo de chegar a cada ponte vizinha ao custo informado (por aquela vizinha) e toma a menor de todas essas somas como sendo o seu próprio custo para chegar até a raiz. Assumindo que a medida de custo utilizado é o número de saltos (isto é, o número de enlaces percorridos também chamados de hops), no caso do exemplo, B calcula sua distância até a raiz como sendo 35+1=36. A seleção da raiz efetuada por B será a ponte de identificador 9 (se o identificador de B fosse menor do que 9, ela própria seria a raiz). 69 Root ID Custo Bridge ID Porta Porta Porta Porta Porta Raiz A porta que corresponde à escolha do menor custo para se chegar à raiz é a eleita porta raiz. Em caso de empate entre duas portas, escolhe-se a porta cuja ponte destino tem o menor identificador. No caso do exemplo, B seleciona a porta 2 como sua porta raiz. Ou Seja: Porta Raiz A porta raiz é aquela porta pela qual se chega à ponte raiz pelo caminho de menor custo Root ID Custo Bridge ID Porta Porta Porta Porta

19 Ponte Designada Tendo selecionado a ponte raiz, calculado sua distância a ela e eleito a porta raiz, uma ponte constrói sua nova mensagem de configuração. No nosso exemplo, o vetor da mensagem de configuração de B (BID=15) seria é melhor do que os armazenados nas portas 1, 3 e 4, B assume (até que receba uma mensagem com vetor melhor em uma dessas portas) que ela própria é a ponte designada nos segementos de rede correspondentes a essas portas Essas portas são denominadas portas designadas Transmite nessas portas a sua mensagem de configuração. Ponte Designada e Porta Designada Ponte Designada Em um segemento de rede, é a ponte que leva à ponte raiz pelo caminho de menor custo. Porta Designada Uma ponte que é a Designada em um segmento, essa é a porta que a conecta a esse segmento Root ID Custo Bridge ID Porta Porta Porta Porta Portas que pertencem à SPT Depois de selecionar a raiz, de calcular seu próprio custo até ela e de eleger a ponte designada em cada rede, as pontes devem decidir quais portas pertencem à arvore geradora. As seguintes portas são selecionadas: A porta raiz As portas designadas. Root ID Custo Bridge ID Porta Porta Porta Porta No nosso exemplo, B escolheria a porta 2 por ser a raiz e as portas 1,3 e 4 por serem designadas. Estados das Portas As portas escolhidas como pertencentes à árvore são colocadas no estado habilitado para encaminhamento (forwarding); As demais portas são colocadas no estado bloqueado (blocked). Quadros de informação recebidos em portas no estado bloqueado são simplesmente ignorados pela ponte (descartados); apenas mensagens de configuração são recebidas, processadas e enviadas pelas portas que se encontram nesse estado. Portanto, ao utilizar o algoritmo de encaminhamento e aprendizado as pontes desconsiderarão as portas bloqueadas. Já as portas habilitadas funcionam como portas normais, recebendo e encaminhando tanto quadros de informação quanto quadros de configuração

20 Árvore Geradora Seguindo todo o processo descrito, decorrido um certo tempo até que a topologia formada se estabilize, tem-se uma configuração na qual as portas raiz e designadas estão no estado habilitado e cada rede tem uma única porta designada. Percebe-se a formação de uma árvore para o encaminhamento dos quadros de informação. B5 B2 B6 B1 B7 B3 Porta Designada Porta Raiz 77 B8 B4 B9 Medida de Custo 78 A medida de custo prevista pelo padrão IEEE 802.1D tem sido constantemente revisada ao longo das últimas versões publicadas. Inicialmente, apenas o número de saltos era a medida utilizada. Parâmetro Taxa do Enlace Custo Recomendado na Revisão de 1998 Custo Recomendado no Adendo de 2001 (IEEE 802.1t) Custo 100 Kbps Custo 1 Mbps Custo 4 Mbps 250 Custo 10 Mbps Custo 16 Mbps 62 Custo 100 Mbps Custo 1Gbps Custo 10 Gbps Custo 100 Gbps 200 Custo 1 Tbps 20 Custo 10 Tbps Porta 1 Exemplo Porta Porta 1 Exemplo Porta Porta 2 92 Porta Considerando que os enlaces são de 10Gbps Porta Taxa do Enlace Custo Recomendado no Adendo de 2001 (IEEE 802.1t) 100 Kbps Mbps Mbps 10 Mbps Mbps 100 Mbps Gbps Gbps Gbps Tbps Tbps Porta 2 92 Porta Porta Reconhecendo que o melhor vetor é aquele armazenado na porta 4, a ponte 92 assume que: 1. a ponte raiz é a de identificador seu custo para a raiz é = sua porta raiz é a porta 4. Com base nessas informações, a mensagem de configuração que a ponte 92 monta para transmitir contém o vetor , que, nesse momento, é melhor do que os armazenados nas portas 1 e 2. Assim, a ponte 92 irá assumir a posição de designada dessas portas, invalidando os atuais vetores nelas armazenados, colocando o vetor da sua mensagem de configuração no lugar

21 Porta 1 Porta 2 92 Porta Porta Designada Porta Raiz Porta Bloqueada Porta 5 Porta 4 Exemplo Quando comparado aos vetores armazenados nas portas 3 e 5, o vetor é pior. O resultado é a seleção das portas 1, 2 e 4 como as portas pertencentes à arvore de cobertura, as duas primeiras por serem portas designadas e a última por ser a porta raiz. Já as portas 3 e 5 serão colocadas no estado bloqueado. Árvore Geradora na Presença de Falhas: Algoritmos de Reconfiguração O algoritmo de árvore geradora apresentado até aqui descreve a forma que a árvore vai sendo montada conforme novas pontes ou enlaces entre elas são introduzidos. É necessário agora entendermos de que forma esse algoritmo deve ser modificado para que a rede possa se reconfigurar em caso de falhas nos enlaces ou pontes existentes Árvore Geradora na Presença de Falhas: Algoritmos de Reconfiguração Árvore Geradora na Presença de Falhas: Algoritmos de Reconfiguração Cada mensagem contém um campo numérico denominado de Message_Age. Ao armazenar vetores de configuração, pontes armazenam também o valor recebido nesse campo. Uma vez armazenado com os vetores de prioridade, o Message_Age é incrementado conforme o decorrer do tempo ao atingir um valor máximo (denominado Max_Age), o vetor é descartado e a ponte refaz seus cálculos. Esse procedimento confere à rede uma capacidade de reconfiguração dinâmica. BPDU de Configuração Protocol ID (2 Bytes) Version (1 Byte) Message Type (1 Byte) Flags (1 Byte) Root ID (8 Bytes) Root Path Cost (4 Bytes) Bridge ID (8 Bytes) Port ID (2 Bytes) Message Age (2 Bytes) Max Age (2 Bytes) Hello Time (2 Bytes) Forward Delay (2 Bytes) Em um funcionamento normal, a ponte raiz deve transmitir periodicamente (a intervalos de tamanho hello_time) suas mensagens de configuração. Nessas mensagens, o valor do Message_Age é zero. Ao receber BPDUs, as pontes vizinhas à raiz também transmitem suas BPDUs nas portas designadas, mais uma vez com o Message Age igual a zero. O processo continua se repetindo até atingir as folhas da árvore, isto é, cada ponte designada que recebe uma BPDU na porta raiz, transmite suas próprias BPDUs nas portas designadas, fazendo com que, nos vetores armazenados, periodicamente, os respectivos Message Age recebam novamente o valor zero. O padrão IEEE prevê que o parâmetro hello_time pode ser configurado pelo administrador do sistema. O valor recomendado como default é de 2 segundos

22 Árvore Geradora na Presença de Falhas: Algoritmos de Reconfiguração Se qualquer elemento (ponte ou enlace) no caminho entre uma ponte e a raiz falhar, essa ponte não mais receberá BPDUs periódicas em sua porta raiz, decorrido um certo tempo (limitado pelo Max_Age), a ponte irá refazer seus cálculos. Dessa forma, falhas farão com que caminhos alternativos passem a ser utilizados, originados pelo cálculo de uma nova árvore de cobertura que evita os caminhos ou pontes em falha. O valor do parâmetro Max_Age segundo o IEEE é configurável, valor default recomendado de 20 segundos. Árvore Geradora na Presença de Falhas Suponha que uma ponte B é a ponte designada em uma determinada rede. Suponha ainda que B não tenha recebido recentemente as BPDUs periódicas. Dessa forma, a mensagem de configuração dessa porta tem, no momento, o campo Message_Age com algum valor igual a X (maior ou igual a zero). Se uma outra ponte C for ativada na mesma rede de B nesse momento, ela enviará sua mensagem de configuração sem ter recebido mensagem alguma de B. Note que enquanto a ponte C não receber alguma mensagem de configuração, ela supõe ser, ela própria, a ponte raiz e divulga essa informação, ocasionando a inserção de caminhos adicionais que podem corresponder a ciclos. Se B receber a mensagem de C (informando ser a raiz) e ainda assim permanecer sem enviar sua mensagem de configuração (isto é, continuar esperando o recebimento de uma BPDU em sua porta raiz para só então enviar sua BPDU), o tempo para que C perceba que ela própria não é a raiz será postergado, piorando a eficiência da rede. Por essa razão, nesse caso, B não espera a recepção da BPDU na porta raiz e envia, o quanto antes, a sua mensagem de configuração contendo o valor do momento (no caso igual a X) para o campo Message_Age. 85 Evitando Ciclos Pode-se perceber que, após uma mudança topológica, seja ela ocasionada por falha ou por ativação de uma ponte ou enlace, existe um intervalo de tempo em que a rede pode apresentar inconsistências. Essas inconsistências podem ocorrer simultaneamente em várias partes da rede podem ser de dois tipos: perdas momentâneas de conectividade, quando uma porta de uma ponte que estava bloqueada na topologia anterior ainda não foi atualizada de forma a se tornar ativada na nova topologia ciclos momentâneos na topologia, quando uma porta de uma ponte que estava habilitada na topologia anterior ainda não foi atualizada de forma a se tornar bloqueada na nova topologia. Evitando Ciclos A probabilidade de inserção de ciclos pode ser minimizada se for estipulado que qualquer ponte deva sempre esperar por um intervalo de tempo adicional antes de passar uma porta do estado bloqueado para o estado habilitado. Se bem dimensionado, esse tempo adicional é o suficiente para que informações sobre portas que devam se tornar bloqueadas já tenham se espalhado

23 Evitando Ciclos: Tempo adicional Suponha que uma ponte B1 é a raiz da árvore em uma topologia a ser modificada e que B1 envia uma primeira mensagem de configuração. Suponha que essa informação se espalha não encontrando qualquer congestionamento, chegando às folhas da árvore em um tempo que consideraremos desprezível. Suponha agora que uma segunda mensagem de configuração de B1 sofre um retardo de T segundos para se espalhar até as folhas da árvore Que, para efeito do exemplo, consideraremos como sendo o pior retardo que se estima para essa rede. Admita que, imediatamente após ter enviado essa segunda mensagem, B1 entra em falha. Nessas circunstâncias, pontes próximas a B1 perceberão a falha e começarão a calcular a nova topologia T segundos antes das pontes mais distantes. Suponha agora que a nova raiz da árvore será uma ponte B2, que está o mais distante possível de B1. Suponha ainda que a primeira mensagem de configuração de B2 (que só será enviada T segundos após a falha) sofre o mesmo retardo de T segundos para se espalhar até a região próxima de B1. Então, a consistência, nesse pior caso, só será readquirida passados 2T segundos da falha. Evitando Ciclos: Tempo adicional Para garantir que a ponte espera o tempo adicional de 2T segundos antes de passar uma porta do estado bloqueado (blocked) para habilitado (forwarding), foi proposta (em [Perlman 85]) a inserção de mais um estado denominado preforwarding. Nesse estado, a porta ainda não é utilizada para encaminhar ou receber quadros de informação, mas já é utilizada para o envio das mensagens periódicas de configuração. Assim que o tempo adicional expira, se a ponte ainda achar, pelos seus cálculos, que aquela porta deve passar para o estado habilitado, então ela efetua alteração. O tempo T é um parâmetro configurável da ponte 90 Máquina de Estados para as Portas do Padrão IEEE 802.1D 91 O IEEE 802.1D elaborou um pouco mais o algoritmo anterior subdividindo o estado preforwarding em dois. Estado de escuta (listening), recebe, processa e encaminha as mensagens de configuração recebidas na porta. Estado de aprendizado (learning), além de receber, processar e encaminhar as mensagens de configuração, também recebe e processa (mas não encaminha) os quadros de informação recebidos pela porta. permite que o aprendizado da estação para a construção da cache de encaminhamento se faça antes do início efetivo do encaminhamento dos quadros supostamente evitando o encaminhamento desnecessário de alguns quadros. Um outro estado também foi incluído para permitir ao administrador da rede desabilitar de forma permanente as portas de uma ponte: o estado desabilitado (disabled). 2 Máquina de Estados para as Portas do Padrão IEEE 802.1D 2 Forwarding 5 4 Disabled 1 Blocking 4 Learning Listening Versão antes da revisão de 2004 que definiu o Rapid Spanning Tree (1) Porta ativada por mecanismo de gerência (2) Porta desativada por mecanismo gerência (3) O algoritmo seleciona a porta como Designada ou Raiz (4) O algoritmo deixa de selecionar a porta como Designada ou Raiz (5) Temporizador expira O padrão IEEE 802.1D recomenda a utilização de um valor, dado por um parâmetro denominado Forward_Delay, como o tempo de espera antes da passagem para do estado Listening para o estado de Learning, e o mesmo parâmetro como o tempo de espera para a passagem do estado Learning para o estado Forwarding. O valor do parâmetro Forward_Delay deve ser configurável pelo administrador do sistema. O padrão recomenda como valor default um tempo igual a 15 segundos. Note então que, para sair do estado blocking para o estado forwarding, a porta demora pelo menos (2 Foward_Delay), que, com o valor recomendado, corresponde a um total de 30 segundos.

24 Valor de Timeout da Tabela de Encaminhamento Pontes aprendem e armazenam a informação de alcançabilidade das estações em uma memória cache É importante estabelecer o tempo após o qual uma entrada dessa cache é descartada. Cache Timeout Estabelecer um tempo adequado parece ser uma tarefa difícil Tempo muito grande pode impedir a entrega de quadros para estações que se movimentaram Tempo muito pequeno faz o tráfego aumentar demais na rede Valor de Timeout da Tabela de Encaminhamento Se a única modificação topológica possível fosse oriunda de movimentação física das estações, um timeout grande (da ordem de minutos) seria razoável: Tempo para desconectar fisicamente a estação, movê-la a outro ponto e reconectá-la fisicamente A estação movimentada dispõe de técnicas para acelerar o funcionamento Mandar um pacote de multicast, por exemplo Valor de Timeout da Tabela de Encaminhamento Porém, movimentar estações não é a única forma de alteração topológica Uma reconfiguração da Spanning Tree é também uma reconfiguração topológica Leva bem menos do que alguns minutos Não há como estações usarem artifícios como multicast pois as mudanças topológicas devido a reconfigurações da spanning tree ocorrem sem o conhecimento das estações finais. Valor de Timeout da Tabela de Encaminhamento Valor de timeout pequeno (da ordem de alguns segundos) não parece ser tão prejudicial Teoricamente seria ruim para um estação que passou alguns segundos sem enviar quadros na rede mas ainda está conectada Porém, se uma estação ficou sem enviar qualquer pacote por um tempo, é de se suspeitar que ela não esteja prestes a receber um volume de tráfego muito grande nos próximos segundos e, portanto, a ausência de informação sobre ela (descartada pelo timeout) não gerará muito tráfego adicional na rede Apesar disso, não se chegou a um valor único para timeout estabeleceu-se que esse valor deve ser configurável 1. Um valor maior para o caso usual 2. Um valor menor a ser usado logo após uma reconfiguração da Spanning Tree 95 96

25 Reconfiguração da Spanning Tree É possível que as pontes saibam que uma reconfiguração da Spanning ocorreu? 97 Pelo menos uma ponte sempre sabe disso quase que imediatamente De uma forma geral, várias outras pontes podem não perceber que ocorreu uma reconfiguração STP foi modificado para incluir um mecanismo de notificação para que as pontes percebam alterações na Spanning Tree Sem gerar aumento de tráfego proporcional ao aumento da topologia Não utilizar multicast, por exemplo Reconfiguração da Spanning Tree Idéia básica do mecanismo de Notificação Quando uma ponte B percebe uma reconfiguração B envia, periodicamente, uma notificação por sua porta raiz utilizando uma mensagem especial denominada Topology Change Notification (TCN) B permanecerá enviando a TCN periodicamente até receber da ponte notificada uma BPDU com a flag Topology Change Acknowlgement (TCA) ligada A ponte que recebe a notificação repete o processo em sua porta raiz Ou seja, envia a TCN na porta raiz A próxima BPDU enviada por essa ponte na porta pela qual a notificação foi recebida terá a Flag TCA ligada Quando a ponte raiz recebe a informação de que houve uma reconfiguração, ela passa a enviar suas BPDUs com uma flag especial (denominada Topology Change Flag TCF) ligada durante um período igual a forward_delay+max_age Sempre que uma ponte recebe uma BPDU com a TCF ligada ela transmite sua própria BPDUs também com essa mesma flag ligada por suas portas designadas 98 Valor de Timeout da Tabela de Encaminhamento Enquanto está recebendo BPDUs com TCF ligada uma ponte utiliza o valor menor para o cache timeout. Configurados ou calculados em cada ponte Configurados pela Ponte Raiz Formato da BPDU no STP Protocol ID (2 Bytes) Version (1 Byte) Message Type (1 Byte) Flags (1 Byte) Root ID (8 Bytes) Root Path Cost (4 Bytes) Bridge ID (8 Bytes) Port ID (2 Bytes) Message Age (2 Bytes) Max Age (2 Bytes) Hello Time (2 Bytes) Forward Delay (2 Bytes) Bit 0 Topology Change Flag Bits 1 ao 6 Reservados Bit 7 Topology Change ACK

26 Formato da TCN Protocol ID (2 Bytes) Version (1 Byte) Message Type (1 Byte) Rapid Spanning Tree Protocol (RSTP) IEEE 802.1: RSTP 103 Motivado pelo tempo razoavelmente elevado de convergência nas reconfigurações topológicas, o grupo responsável pelo IEEE propôs algumas modificações ao STP (Spanning Tree Protocol) transformando-o no RSTP (Rapid STP) Inicialmente, descritas no documento IEEE 802.1w Em 2004, incorporadas ao IEEE 802.1D IEEE 802.1: RSTP O grupo responsável pelo IEEE também reconheceu que havia uma série de conceitos sobrecarregados no que dizia respeito aos papéis e estados das portas do IEEE 802.1D Por exemplo: do ponto de vista operacional, não há diferença entre uma porta no estado blocked e uma no estado listening Ambas descartam quadros e não aprendem com o tráfego A real diferença está no papel que a porta pode assumir Sabe-se que uma porta no estado listening é : uma porta raiz que está a caminho do estado forwarding ou é uma porta designada que está a caminho do estado forwarding Infelizmente, depois de estar no estado forwarding, não há como saber, pela máquina de estados, se a porta é raiz ou se é designada. Por isso, com o RSTP, resolveu-se separar o conceito de estado (operacional) do conceito de papel. 104

27 RSTP: Estados No RSTP há apenas 3 estados Discarding, Learning e Forwarding RTSP: Papéis O papel de uma porta passou a ser uma espécie de variável de estado associada àquela porta. Os papéis root e designated continuam a existir. O antigo estado Blocking gerou dois papéis: Backup Alternate Obs: é muito comum denominar o estado Discarding do RSTP de Blocking (implementações Cisco) Root Ports Alternate Port Papéis das Portas Designated Ports Backup Port RSTP BPDUs são enviadas nas portas designadas por todas as pontes a cada <Hello_Time> No STP, pontes enviavam BPDUs apenas após o recebimento, em sua porta raiz de uma BPDU A ponte raiz acabava por comandar o processo No RSTP, pontes tem seu próprio relógio e enviam, independente de terem recebido BPDUs na porta raiz, BPDUs a cada <Hello_Time> Se BPDUs não são recebidas em uma porta por um período superior a 3 x Hello_Time O vetor armazenado naquela porta é descartado e a ponte refaz seus cálculos Não é mais necessário esperar que o Message_Age atinja o Max_Age como no STP

28 RSTP: Transições Rápidas Rapid transition is the most important feature introduced by 802.1w. The legacy STA passively waited for the network to converge before it turned a port into the forwarding state. The achievement of faster convergence was a matter of tuning the conservative default parameters (forward_delay and max_age timers) and often put the stability of the network at stake. The new rapid STP is able to actively confirm that a port can safely transition to the forwarding state without having to rely on any timer configuration. There is now a real feedback mechanism that takes place between RSTP-compliant bridges. In order to achieve fast convergence on a port, the protocol relies upon two new variables: edge ports and link type. Edge Ports All ports directly connected to end stations cannot create bridging loops in the network. Therefore, the edge port directly transitions to the forwarding state and skips the listening and learning stages Link Types 111 RSTP can only achieve rapid transition to the forwarding state on edge ports and on point-topoint links. The link type is automatically derived from the duplex mode of a port. A port that operates in full-duplex is assumed to be point-to-point, while a half-duplex port is considered as a shared port by default. This automatic link type setting can be overridden by explicit configuration. 2 2 Forwarding 5 4 Disabled 1 Blocking 4 Learning 2 Convergência no STP Listening (1) Porta ativada por mecanismo de gerência (2) Porta desativada por mecanismo gerência (3) O algoritmo seleciona a porta como Designada ou Raiz (4) O algoritmo deixa de selecionar a porta como Designada ou Raiz (5) Temporizador expira O padrão IEEE 802.1D recomenda a utilização de um valor, dado por um parâmetro denominado Forward_Delay, como o tempo de espera antes da passagem para do estado Listening para o estado de Learning, e o mesmo parâmetro como o tempo de espera para a passagem do estado Learning para o estado Forwarding. O valor do parâmetro Forward_Delay deve ser configurável pelo administrador do sistema. O padrão recomenda como valor default um tempo igual a 15 segundos. Note então que, para sair do estado blocking para o estado forwarding, a porta demora pelo menos (2 Foward_Delay), que, com o valor recomendado, corresponde a um total de 30 segundos.

29 Convergência no STP Convergência no RSTP Enlace recém adicionado Ambas as portas no enlace entre A a raiz passam ao estado designated blocking assim que são levantadas. Até aqui tudo se comporta como no ambiente do STP. Porém, nesse estágio, uma negociação acontece entre A e a Raiz. Logo que A recebe a BPDU da Raiz, ele bloqueia todas as portas designadas que não são edge-ports. Essa operação é denominada sync. Em poucos segundos a porta P1 estará bloqueada mas o enlace entre Root e A só passará a Forwarding decorrido 2 x Forward_Delay Feito isso, A autoriza explicitamente a ponte Raiz a colocar sua porta no estado de forwarding Dessa forma impede-se o ciclo loop de uma forma diferente: ao invés de bloquear acima do Switch A, a rede agora bloqueia abaixo Switch A. Ou seja: os potenciais ciclos são cortados em um ponto diferente. Este corte viajará pela árvore. Convergência no RSTP Assim que o Switch A bloqueia suas non-edge designated ports, o enlace entre ele e a raiz é então colocado no estado forwarding Other than the root port towards A, Switch B only has edge designated ports. Therefore, it has no port to block in order to authorize Switch A to go to the forwarding state. Similarly, Switch C only has to block its designated port to D. The state shown in this diagram is now reached: Convergência no RSTP Neste estágio, as novas portas bloqueadas no Switch A também negociam uma transição rápida para o estado de forwarding com as portas vizinhas nos Switches B e C, inciando a operação de Sync. 115 Remember that the final topology is exactly the same as the 802.1D example, which means that port P1 on D ends up blocking. This means that the final network topology is reached, just in the time necessary for the new BPDUs to travel down the tree. No timer is involved in this quick convergence. The only new mechanism introduced by RSTP is the acknowledgment that a switch can send on its new root port in order to authorize immediate transition to the forwarding state, and bypasses the twice-the-forward-delay long listening and learning stages. 116

30 RTSP The negotiation between bridges is only possible when bridges are connected by point-to-point links that is, full-duplex links unless explicit port configuration. Proper configuration of Edge ports play an important role. For instance, if the network administrator fails to properly configure the edge ports on B, their connectivity is impacted by the link between A and the root that comes up. RSTP Negotiation: Proposal/Agreement Sequence Suppose a new link is created between the root and Switch A. Both ports on this link are put in a designated blocking state until they receive a BPDU from their counterpart. When a designated port is in a discarding or learning state (and only in this case), it sets the proposal bit on the BPDUs it sends out. This is what occurs for port p0 of the root bridge, as shown in step 1 of the diagram. Because Switch A receives superior information, it immediately knows that p1 is the new root port. Switch A then starts a sync to verify that all of its ports are in-sync with this new information. A port is in sync if it meets either of these criteria: The port is in the blocking state, which means discarding in a stable topology. The port is an edge port Configurados ou calculados em cada ponte Configurados pela Ponte Raiz BPDU do RSTP Protocol ID (2 Bytes) Version (1 Byte) Message Type (1 Byte) Flags (1 Byte) Root ID (8 Bytes) Root Path Cost (4 Bytes) Bridge ID (8 Bytes) Port ID (2 Bytes) Message Age (2 Bytes) Max Age (2 Bytes) Hello Time (2 Bytes) Forward Delay (2 Bytes) Version 1 Length (1 Byte) Bit 0 Topology Change Flag Bit 1 Proposal Bit 2-3 Port Role 00 Unknown 01 Alternate or Backup Port 10 Root Port 11 Designated Port Bit 4 - Learning Bit 5 - Forwarding Bit 6 - Agreement Bit 7 Topology Change ACK RSTP Negotiation: Proposal/Agreement Sequence Suppose a new link is created between the root and Switch A. Both ports on this link are put in a designated blocking state until they receive a BPDU from their counterpart. When a designated port is in a discarding or learning state (and only in this case), it sets the proposal bit on the BPDUs it sends out. This is what occurs for port p0 of the root bridge, as shown in step 1 of the diagram. Because Switch A receives superior information, it immediately knows that p1 is the new root port. Switch A then starts a sync to verify that all of its ports are in-sync with this new information. A port is in sync if it meets either of these criteria: The port is in the blocking state, which means discarding in a stable topology. The port is an edge port. Campos atualizados pelo RSTP

31 RSTP Negotiation: Proposal/Agreement Sequence RSTP Negotiation: Proposal/Agreement Sequence Notice that p2 and p4 already meet one of the criteria. In order to be in sync (see step 2 of the diagram), Switch A just needs to block port p3, and assign it the discarding state. Now that all of its ports are in sync, Switch A can unblock its newly selected root port p1 and send an agreement message to reply to the root. (see step 3). The Agreement message is a copy of the proposal BPDU, with the agreement bit set instead of the proposal bit. This ensures that port p0 knows exactly to which proposal the agreement it receives corresponds. Once p0 receives the agreement, it can immediately transition to the forwarding state. This is step 4 of the figure. Notice that port p3 is left in a designated discarding state after the sync. In step 4, that port is in the exact same situation as port p0 is in step 1. It then starts to propose to its neighbor, and attempts to quickly transition to the forwarding state RSTP Negotiation: Proposal/Agreement Sequence The proposal agreement mechanism is very fast, as it does not rely on any timers. A wave of handshakes that propagates quickly towards the edge of the network, Quickly restores connectivity after a change in the topology. If a designated discarding port does not receive an agreement after it sends a proposal, it slowly transitions to the forwarding state falls back to the traditional 802.1D listening-learning sequence. This can occur if the remote bridge does not understand RSTP BPDUs, or if the port of the remote bridge is blocking. Uplink Fast Another form of immediate transition to the forwarding state is included in RSTP similar to the Cisco UplinkFast proprietary spanning tree extension When a bridge loses its root port, it is able to put its best alternate port directly into the forwarding mode. The selection of an alternate port as the new root port generates a topology change. Alternate Port

32 New Topology Change Mechanisms The Old STP Mechanism This topology change mechanism is deeply remodeled in RSTP. Both the detection of a topology change and its propagation through the network evolve. New Topology Change Detection Mechanism In RSTP, only non-edge ports that move to the forwarding state cause a topology change. This means that a loss of connectivity is not considered as a topology change anymore, contrary to the old STP, a port that moves to blocking no longer generates a TC. When a RSTP bridge detects a topology change It starts the TC While timer with a value equal to twice the hello-time for all its non-edge designated ports and its root port, if necessary. As long as the TC While timer runs on a port, the BPDUs sent out of that port have the TC bit set. BPDUs are also sent on the root port while the timer is active. It flushes the MAC addresses associated with all these ports New Topology Change Propagation Scheme When a bridge receives a BPDU with the TC bit set from a neighbor It clears the MAC addresses learned on all its ports, except the one that receives the topology change. It starts the TC While timer and sends BPDUs with TC set on all its designated ports and root port RSTP no longer uses the specific TCN BPDU, unless a legacy bridge needs to be notified. New Topology Change Propagation Scheme TCN floods very quickly across the whole network. The TC propagation is now a one step process. In fact, the initiator of the topology change floods this information throughout the network, as opposed to the old STP where only the root did. This mechanism is much faster than the old STP equivalent. There is no need to wait for the root bridge to be notified and then maintain the topology change state for the whole network for <max_age+forward_delay> seconds