MPLS Core — Traffic Engineering
Neste post irei continuar descrevendo por dentro do CORE MPLS de um Service Provider, se você ainda não conhece o post anterior, é só clicar aqui.
Em um Service Provider é crucial um bom planejamento com as tecnologias disponíveis nos ativos que compõe o backbone para fazer total uso da largura de banda disponível, para esse proposito iremos focar neste post no protocolo RSVP. Espero que você curta bastante a leitura. Não esquece de me seguir aqui e ao TechRabels clicando follow lá em cima.
Este é o cenário que irei explorar e utilizar engenharia de trafego sobre os links deste Service provider, de forma a atender os requesitos do serviços.
Recapitulando o protocolo RSVP, trouxe melhorias sobre o LDP além de distribuir labels dos prefixos originidos do IGP (OSPF/IS-IS), possue a capacidade de reserva de recursos (ex. largura de banda).
O IGP escolhido deverá ser habilitado para carregar os atributos de engenharia de trafego a todos os roteadores (tratando-se de OSPF/IS-IS ambos possuem a completa visão de links de toda a rede), com o OSPF essa informação é transportada via LSA-10, e para o IS-IS via TLV.
Em nosso cenário a saída do OSPF DATABASE LSA-10 enviados pelo P1 para os routers do backbone.
A saída abaixo refere-se ao protocolo RSVP a qual possui os valores configurados de forma estática (definidas pela Engenheiro de Redes), pode ser definido para usar todo o recurso disponível ou administra-lo e manipular a banda para que seja utilizado por outros LSP's estáticos (Que pode ser um outro serviço).
O cenário neste momento está implementado com MPLS/LDP/RSVP e irei seguir com a configurações do LSP para os serviços mencionados no post anterior VOZ e VíDEO.
Oberserve a saída do comando show rsvp interface, que está reproduzindo mais uma vez a saída do P1 compare com a imagem da saída anterior e percebemos que o RSVP alocou os valores do LSP e que existe LSP's Bidirecionais (entre PE1 e PE2), seguindo com a saída observe a saída do comando show mpls lsp transit (transit devido aos P's não serem a origem ou destino do LSP).
Os PE routers possuem uma descrição técnica Headend e TailEnd, brevemente Headed origem do LSP e TailEnd destino do LSP. Nos Juniper esses são identificados como Ingress/Headed e Egress/TailEnd. Observando a imagem abaixo, e partindo do PE1 os LSP name TO-PE2 são Headed em PE1 e os LSP TO-PE1 são TailEnd em PE1.
Vamos responder a pergunta do post anterior? Navegando ao core do Service Provider, os tuneis LSP estarão trafegando por um único PATH? Não….. Devido aos requesitos do LSP que precisamos configurar recorda? 5M para voz e 30M para vídeo. O LSP de vídeo não é atendido via P2, pois este PATH não possui largura de banda suficiente para estabelecer o túnel LSP, ou seja, se o link P1 e P3 falhar o LSP de vídeo/serviço de vídeo ficará indisponível até a recuperação do enlace.
Vamos checar?
Espero que tenha ficado claro o objetivo deste post, para o próximo pretendo evoluir com diferenças entre OSPF e IS-IS.
Você conhece o IGP IS-IS, tem experiência com IS-IS? Vai ser legal contar com sua presença aqui.
Grande abraço!
Sobre o autor:
Renato Antonio é Engenheiro de Redes na Tely. Graduado em Redes de computadores pela Unibratec, certificado CCIE RS pela Cisco Systems e JNCIS-SP pela Juniper.
#Juniper #ServiceProvider #TrafficEngineering #RSVP #LDP #ISIS #JNCIS-SP #CCIE
