Para uma melhor análise dos comandos efetuados nesta seção, através da ferramenta SNMP Traffic Grapher extraímos os gráficos nas saídas das interfaces serial1/2 e serial1/3, do PE1, e serial1/2, do P1, conforme podemos analisar na Figura 8.12. O tráfego foi gerado a partir da ferramenta TfGen.
Para geração do tráfego e visualização dos gráficos, foi feita uma conexão ló- gica entre a placa de rede de uma estação real e a placa de rede virtual do roteador CE11, conforme Figura 8.12. Todo tráfego foi gerado com origem no PC (10.1.1.2) e destino a loopback0 do CE22 (200.2.0.2), fazendo o tráfego percorrer todo o back-
bone. As rotas necessárias para este teste também foram inseridas no roteador PE1. Observação: todas as configurações efetuadas nos roteadores e os testes rea-
lizados encontram-se no Apêndice E desta obra.
Inicialmente foi feita uma análise sem a aplicação da engenharia de tráfego, onde percebemos que, como o protocolo de roteamento IS-IS escolhe o melhor caminho, os demais ficarão ociosos e apenas serão utilizados como redundância. Neste caso, o caminho utilizado pelo IS-IS do PE1 para o PE2 foi via P2, escolhido aleatoriamente por este protocolo em virtude dos caminhos PE1 à P1 à PE2 e PE1 à P2 à PE2 terem o mesmo custo. Neste caso, ocorreria um balanceamento, mas por sessão (o protocolo utiliza sempre o mesmo enlace após estabelecimen- to da sessão entre origem e destino), deixando os demais enlaces ociosos.
A geração de tráfego para todos os testes desta seção foi feita conforme a Figura 8.13. Podemos visualizar os gráficos obtidos através das Figuras 8.14 e 8.15.
Figura 8.13 – Tráfego gerado do PC para o CE22
Pode-se observar que só há tráfego efetivo na interface serial1/3, pois o caminho escolhido pelo protocolo foi PE1 à P2 à PE2, deixando os demais cami- nhos ociosos – inclusive podendo ter perda de pacotes quando o tráfego excede o limite permitido pela interface.
Após criação dos dois túneis iniciais para engenharia de tráfego (túnel 0 e túnel 1), conforme Figura 8.12, fizemos os mesmos testes e podemos perceber que, nesse caso, dois caminhos estão sendo utilizados. Um deles é o caminho PE1 à P1 à PE2, utilizado pelo túnel 0, e o outro é o caminho PE1 à P2 à PE2, utili- zado pelo túnel 1. Há também um caminho ocioso, conforme podemos verificar no gráfico de saída da interface serial1/2 do P1, Figura 8.18, o que é completa- mente aceitável, pois os túneis definidos não fazem uso desse caminho. Podemos visualizar todos os gráficos nas Figuras 8.16, 8.17 e 8.18.
Figura 8.15 – Visualização do tráfego na saída da interface serial1/3 do PE1
Com a criação de um terceiro túnel (túnel 2), observamos que agora temos tráfego também através do caminho PE1 à P1 à P2 à PE2. Sendo assim, os três caminhos estão sendo utilizados, balanceando a carga no backbone e propician- do redundância, pois, caso um dos túneis venha a falhar, os demais assumem a carga normalmente, o que pode ser visto no Apêndice E. A menor utilização de recursos através do túnel 2 ocorre devido ao túnel ter sido criado com requeri- mento de banda menor, o que comprova que a distribuição de carga está sendo feita conforme definido pelo administrador. Os gráficos podem ser visualizados nas Figuras 8.19, 8.20 e 8.21.
Figura 8.17 – Visualização do tráfego na saída da interface serial1/3 do PE1
Figura 8.19 – Visualização do tráfego na saída da interface serial1/2 do PE1
Figura 8.20 – Visualização do tráfego na saída da interface serial1/3 do PE1
A engenharia de tráfego habilita os ISPs a rotear o tráfego na rede para prover melhor serviço aos usuários, em termos de taxa de transferência (throughput) e atraso (delay). Tornando o provedor mais eficiente, a engenharia de tráfego reduz o custo na rede, tendo como grande vantagem o melhor aproveitamento dos enlaces.
Nesta simulação, podemos observar que, através da criação de túneis uni- direcionais dinâmicos e/ou explícitos, podemos distribuir o tráfego no backbone de forma a permitir o balanceamento de carga e redundância na rede.
Inicialmente, criamos dois túneis (túnel 0 e túnel 1) e observamos o comportamento do roteamento no backbone. Vimos que o tráfego foi distribuído igualmente pelos dois caminhos utilizados, sendo um deles dinâmico e o outro explícito. Tal comportamento se dá devido aos parâmetros de configuração dos túneis serem idênticos. Nesta simulação vimos também que, caso um dos túneis fique inativo, o tráfego será enviado normalmente pelo túnel ativo, garantindo também a redundância na comunicação.
Em seguida mantivemos os dois túneis e criamos um terceiro túnel, o qual chamamos de túnel 2, que iria seguir por um outro caminho, mas com o mesmo destino, solicitando metade da banda requisitada pelos túneis iniciais.
Após sua criação, notamos o balanceamento de carga entre os três túneis através do gráfico fornecido, porém distribuído de acordo com a razão da banda alocada entre eles. Através da tabela de roteamento e testes com o traceroute par- tindo do head-end em direção ao tail-end, podemos constatar o balanceamento, nesse caso, entre os três caminhos.
Para melhor entendimento, fizemos toda uma análise gráfica desse cenário de engenharia de tráfego.
Tabela 8.3 – Tabela comparativa das tecnologias e serviços agregados
Serviços/Tecnologias ATM FR MPLS Limite – Banda comercializada 622 Mbps 2 Mbps Ilimitada PseudoWire ---- ---- Transporte de quaisquer tecnologias VPN Não escalável
N(N-1)/2 Não escalávelN(N-1)/2 Escalável – Full Mesh
QoS Apenas nas bordas Apenas nas bordas Fim-a-fim
TE ---- ---- Criação de túneis
para distribuição de carga
Na Tabela 8.3 foram resumidas as informações relativas aos serviços utili- zados pela tecnologia MPLS em comparação com as tecnologias legadas, ATM e
Frame Relay.