Arquitetura IP-VPN e QoS do Serviço Vetor Release II

Descrição de Arquitetura
Serviço Vetor – Release II
DIRETORIA DE REDE
31 / 01 / 2007 – VERSÃO 5.8

ARQUITETURA DO SERVIÇO BRASIL TELECOM
VETOR - REL. II DIRETORIA DE REDE
Índice
Introdução ......................................................................................................................... 4
1. Descrição da Arquitetura de Rede .......................................................................... 4
2. Características das VPNs......................................................................................... 5
3. Acessos Dedicados (CPEs) ....................................................................................... 9
4. Agregador Multisserviços (Juniper ERX) ............................................................11
5. Roteadores de Acesso (Cisco 7500 / 7600) ............................................................13
6. Rede Frame Relay / ATM ......................................................................................14
7. Rede IP / MPLS ......................................................................................................16
8. Acesso Remoto ........................................................................................................18
9. RADIUS / LDAP / SDX..........................................................................................20
10. Gerência ...............................................................................................................21
11. Quality of Service (QoS).....................................................................................22
12. Extranets para acesso a serviços de valor adicionado (conteúdo)..................23
13. Interconexão (VPN Inter-AS)............................................................................25
14. Multicast para MPLS/VPN................................................................................26
15. Anexo I: Configuração de CPEs........................................................................29
16. Anexo II: Mapeamento de Aplicativos .............................................................30
17. Anexo III: Configuração IPSEC (ERX e Cliente) ...........................................31
17.1. Requisitos do Sistema Operacional do cliente ..............................................31
17.2. Requisitos de Hardware e sistema Operacional do ERX ............................31
17.3. Parâmetros necessários antes de se configurar cliente ou ERX .................31
17.4. Procedimentos de configuração .....................................................................31
18. Anexo IV: Configuração IPSEC (ERX e Netscreen).......................................33
18.1. Requisitos do Sistema Operacional do Netscreen........................................33
18.2. Requisitos hardware e Sistema Operacional do ERX.................................33
Diretoria Adjunta de Tecnologia e Arquitetura Versão 5.8 Página 2 de 56

18.3. Requisitos e restrições da Rede .....................................................................33

18.4. Parâmetros necessários antes de se configurar o Netscreen ou ERX........33
18.5. Procedimentos de configuração .....................................................................34
19. Anexo V: Solução VISANET .............................................................................36
19.1. Configuração de referência ............................................................................37
20. Anexo VI: Multicast ...........................................................................................40
20.1. Requisitos de Hardware e Sistema Operacional dos Roteadores...............40
21. Anexo VII: Solução CARD ................................................................................42
21.1. Topologia genérica ..........................................................................................42
21.2. Solução dedicada em IP..................................................................................45
21.3. Solução dedicada IP / X.25 .............................................................................47
21.4. Solução discada ...............................................................................................48
21.5. Exemplo de configuração XOT (X.25 ove r TCP)........................................49
Chamada do numero X.25 48710012345 para Embratel 14802521..................................54
Debug conexão ................................................................................................................54
Debug conexão ................................................................................................................55
Debug conexão: ...............................................................................................................55

Introdução
Este documento apresenta a arquitetura para o atendimento do serviço Vetor, as características do serviço,
principais requisitos técnico-operacionais e limitações e evolução do serviço.
Este documento considera somente a Release II do serviço, sem as limitações associadas a Release I.
O serviço Vetor possui duas características básicas:
Ø Formação de uma IP-VPN, permitindo o acesso através de tecnologias diversas (xDSL, TDM, FR);
Ø QoS (Quality-of-Service), através da distinção das aplicações do cliente, são fornecidas quatro
classes de serviço distintas, de acordo com os requisitos dos aplicativos envolvidos.
Uma IP-VPN (IP Virtual Private Network) é uma rede privada em Layer-3 (rede), ou seja, a operadora passa
a ser parte integrante do roteamento IP do cliente.
1. Descrição da Arquitetura de Rede

Basicamente, este serviço estará baseado na integração das diversas tecnologias de comunicação de dados
existentes, com a introdução de novas funcionalidades na Rede IP.
A arquitetura para atendimento do Serviço Vetor é apresentada na figura abaixo.
Nesta figura, são apresentadas as diversas formas de acesso possíveis para este serviço: TDM (acessos
determinísticos), Frame Relay (FR), ATM, xDSL (ADSL ou G.SHDSL), acessos remotos (discados – dial-up
e IPSec – acessos provenientes da Internet).

2. Características das VPNs

Para a implantação de forma adequada deste serviço, será necessário que sejam levantados diversos
dados com o cliente e definidos pela Brasil Telecom diversos parâmetros antes do aprovisionamento dos
equipamentos envolvidos.
2.1. DADOS A SEREM FORNECIDOS PELO CLIENTE:
Ø Identificação:
o ID VPN (Nome de 15 caracteres)
Ø Para cada acesso (independente da forma de acesso):
o Endereço IP de interface WAN e máscara associada
o Protocolo de roteamento utilizado e parâmetros associados:
§ Rota estática
• Endereços de Rede Local (LAN e DMZ)
§ RIPv2
• Métrica
§ eBGP
• AS (Autonomous System)
• Métrica
Devido a restrições envolvendo a implementação do processo de OSPF, tanto na plataforma Juniper

ERX quanto Cisco 7500/7600/10000, este protocolo não deverá ser utilizado na conexão CE-PE.
Por ser um protocolo proprietário, o EIGRP n ão deverá ser utilizado na conexão CE-PE.
o Aplicações associadas a cada uma das quatro Classes de Serviço:

§ Endereços IP (E-mail server, Gatekeeper, SAP Server, WEB Server, etc)
§ Aplicações: ftp, http, telnet, VoIP, SAP, e-mail, multimídia, etc
§ Portas TCP / UDP utilizadas para as aplicações
o Banda contratada (LIMITE MÁXIMO, não confundir com mínimo garantido) para cada Classe
de Serviço, em intervalos de 32kbps
NOTA: Regularmente, clientes adquirem determinados números de canais de voz (troncos) para cada
acesso. Para um dimensionamento adequado, será necessário que o cliente informe qual o método / taxa
de compressão utilizado pelas aplicações de voz. P. ex. Utilizando CODEC G.729 e dois troncos de voz,
serão necessários 48kbps para Classe de Serviço “Voz”.
Ø Para cada acessos xDSL:
o DHCP Server:
§ Cliente (Local)
§ Cliente (Relay): Endereço IP do Servidor DHCP
§ BrT
Ø Possui RADIUS Server próprio ou deseja manter a base de usuários / password nos servidores da
Brasil Telecom, neste caso informar qual o número de usuários.

2.2. DADOS A SEREM DEFINIDOS PELA BRASIL TELECOM:

Ø Identificação de VPN:
• Nome: campo alfanumérico de 15 caracteres, este nome será utilizado para identificação da VRF
a ser utilizada pelo cliente em todos os PEs (Roteador de Acesso e Agregador Multisserviços);
• Route-distinguisher (RD): Caso o cliente não possua conexão a Extranets, identificação da
VPN, caso contrário, identificação do Site.
§ Formato:
8167 (AS BrT, 16 bits) : ID_VPN (32 bits)
• Route-target (RT): Identificação das Rotas IP a ser trocada entre os PEs.
§ Formato:
8167 (AS BrT, 16 bits) : ID_VPN (32 bits)
§ Para Cliente VIP Report, será necessário que os endereços de CPEs (Interface WAN ou
Loopback) também sejam associados ao RT reservado para o VIP (8167:1001)
• Valor de RD e RT: Os valores a serem utilizados para RD e RT deverão seguir a tabela abaixo:
Route Distiguisher Route Target Observações
Reservados 000.000.000 000.000.999 Valores reservados, utilizados em communities BGP BrT
Serviços BrT 000.001.000 000.009.999 Serviços providos pela Brasil Telecom
VoIP - 000.001.000 - 000.001.000 RT de equipamentos NGN (gateways, softswitch, etc)
Somente para clientes VIP Report que não possuam IP-
VIP 000.001.001 000.002.999 - 000.001.001
VPN (MPLS), em caso contrário, utilizar RD existente
VPNs 000.010.000 000.999.999
Nacional 000.010.000 000.099.999 000.010.000 000.099.999
RT = RD
Regional 000.100.000 000.999.999 000.100.000 000.999.999
PR (CTA) 000.410.000 000.410.999
SC (FNS) 000.480.000 000.480.999
000.xx0.000, onde xx é o código de área da VPN
RS (PAE) 000.510.000 000.510.999
DF (BSA) 000.610.000 000.610.999
Rotas a serem exportadas pelo "cliente" serão
Extranets 001.000.000 002.009.999 001.000.000 001.999.999
associadas a um RT=RD (fornecedor)
Clientes 001.000.000 001.999.999 000.010.000 000.999.999 RD de sites da VPNs que são "clientes" de Extranets, 6
002.000.000 002.009.999 últimos dígitos são o mesmo que identificam VPN
Fornecedores 002.000.000 002.009.999 002.000.000 002.009.999 RD de sites da VPNs que são "fornecedores" de
Extranets
Ø Serão oferecidas quatro Classes de Serviço (CoS), onde cada uma delas deverá atender aos requisitos
abaixo.
Classe de Serviço Perda de Retardo

(CS) Pacotes
Voz <1% <90 ms
Multimídia <1% <100 ms
Dados Expressos <2% <100 ms
Dados N/A <100 ms
Tais parâmetros são válidos desde que as seguintes condições sejam obedecidas:
1. Tamanho do pacote que deve ser usado nas medições = 100 bytes;
2. A velocidade mínima dos acessos deverá ser de 128 kbps;
3. Os “links” de acesso devem estar com baixa carga.
4. Os parâmetros de desempenho dependem da distância entre os acessos. A tabela é válida para distâncias
entre acessos menores que 1000 Km (Hum mil quilômetros);
5. Os parâmetros de desempenho dependem da velocidade dos entroncamentos da Rede IP. A tabela não é
válida para acessos de Rondônia e do Acre;

6. Os parâmetros de retardo e perda de pacotes deverão ser medidos através do módulo de software Cisco
IOS IP SLA (antigo SAA) UDP Jitter Operation;
7. Os clientes deverão contratar o serviço VIP Report para que os relatórios fim-a-fim possam ser
disponibilizados. As medições devem ser uni-direcionais. A periodicidade da coleta deverá ser de 15
minutos, sendo armazenada/plotada a média das medições do período. A periodicidade da medição
deverá ser a padrão do IP SLA:
UDP Jitter default settings:
• Frequency = 1 minute
• Interval = 20 milliseconds
• Number of Packets = 10
2.3. ROTEAMENTO IP NA VPN:

Ø Diferentemente dos serviços existentes (p.ex. Frame Relay e SLDD) baseados em transporte Layer-1
ou Layer-2, a rede IP-VPN será parte “ativa” da Rede Corporativa do cliente, isto é, será necessário
que a Brasil Telecom atue diretamente com o cliente para configuração adequada dos protocolos de
roteamento IP utilizados.
Ø Por exemplo, a Rede IP da Brasil Telecom se comportará como um único equipamento, isto é, será
apenas um hop IP para a VPN do cliente..
Ø Roteamento Dinâmico
• Diferentes protocolos de roteamento no acesso poderão ser combinados em uma mesma VPN,
isto é, uma VPN pode ter um acesso utilizando RIPv2 e um outro acesso utilizando eBGP.
• Métrica: deverão ser definidas, junto ao cliente, as métricas a serem utilizadas pela Brasil
Telecom, para troca de rotas via RIP e qualquer outro protocolo de roteamento dinâmico que
venha a ser suportado. Por default, será utilizada métrica transparente, isto é, as métricas
recebidas pelo IGP serão replicadas no MP-BGP e vice-versa.
• Para os cenários em que o cliente possuir diferentes protocolos de roteamento em diferentes
acessos, será necessário solicitar as métricas desejadas pelo cliente para as rotas que serão
anunciadas para cada protocolo e/ou rota;
• eBGP: Clientes poderão realizar trocas de rotas utilizando eBGP, com a principal vantagem da
escalabilidade no número de rotas na tabela de roteamento. O cliente deverá ser informado que
serão trocadas somente rotas da IP-VPN do cliente, sem troca de rotas “públicas” (Internet).
• Tabela de Roteamento Pública (Internet): Para os casos de clientes que necessitem de
divulgar as rotas públicas dentro de sua Rede Corporativa, seja completa ou parcial, deverá ser
indicado ao cliente que utilize iBGP entre seus próprios roteadores (CPEs) para realização de
troca de rotas. Roteadores da BrT (PEs) não participarão da troca destas rotas.
• Estabilidade e Escalabilidade: O número máximo de rotas permitidas para cada cliente será
limitado em 500 rotas IP, a fim de possibilitar uma maior estabilidade tanto para a rede do
cliente quanto para a Rede IP BrT. Este limite permitirá o atendimento de redes de
aproximadamente 500 acessos, abrangendo a maior parte dos clientes previstos; caso um cliente
possua uma tabela de roteamento maior, este limite poderá ser modificado sob demanda.

• Route Leaking: Existe a possibilidade da IP-VPN da Brasil Telecom ser um fornecedor entre
outras operadoras de acesso para composição da Rede Corporativa de um determinado cliente.
Caso este cliente faça uso de roteamento dinâmico, podem acontecer redistribuições de rotas
indesejáveis ou inadequadas, conforme o diagrama abaixo. Será necessária a implementação de
filtros de rotas e/ou ajuste em métricas de rotas nos CPEs e VRF do cliente. A figura abaixo
ilustra a situação, onde um CPE utiliza um caminho não-otimizado.
Route Reflector
(MPLS -VPN)
Rede
MPLS
Redistribuicao Redistribuicao
BGP -> IGP IGP -> BGP
PE PE
CPE
A
CPE
CPE CPE
Anuncio de Rota IGP

Anuncio de Rota BGP
Dados (payload)

3. Acessos Dedicados (CPEs)

Para acessos xDSL, ATM e FR, será fornecido ao cliente 1 (um) PVC VBR-nrt (ADSL, ATM) dedicado
ao serviço VETOR. Acesso Internet deverá ser fornecido através de outro PVC ou acesso, seguindo as
modalidades de serviços atualmente disponíveis (IP Dedicado, Light ou Turbo).
Acessos xDSL serão, necessariamente, baseados em PPPoA, ou seja, não deverão ser utilizados DSLAM
Ethernet para aprovisionar clientes Vetor.
Para clientes que adquirirem o serviço Vetor sem QoS, o CPE não necessitará de nenhuma
funcionalidade envolvendo classificação, marcação e policing .
Para acessos com QoS, o CPE será responsável pela classificação, marcação, priorização e limitação
(policing / traffic shaping) dos pacotes IP, seguindo as classes de serviço contratadas pelo cliente. Em
função dessas necessidades, o CPE deverá ser administrado somente pela Brasil Telecom. Caso, o CPE
seja administrado pelo cliente poderão ocorrer fraudes nas classes de serviço.
Para acessos com velocidades iguais ou inferiores a 768kbps, deverão ser aplicadas as funcionalidades de
fragmentation e interleaving. É importante notar que esta funcionalidade é necessária para eliminar o
problema de serialização na interface de acesso do cliente, portanto, a taxa de transmissão a ser
considerada é do meio físico de acesso e não da banda contratada pelo cliente.
Para acessos ADSL (PPPoA), o processo de autenticação deverá ser através de CHAP por questões de
segurança.
NOTAS:
• Não deverá ser ativado header compression para RTP / RTCP (cRTP);
• Para clientes que utilizem protocolos de tunelamento baseados em IP (p.ex. L2TP, PPTP, IPSec)
fim-a-fim, para a diferenciação de Classes de Serviços distintas dentro de um mesmo túnel será
necessária a utilização de CPEs com suporte a esta funcionalidade;
• Para clientes com aplicativos de voz, vídeo-fone e vídeo conferência (baseados tanto em software
quanto hardware), o cliente será responsável pela limitação das chamadas simultâneas, por exemplo,
utilizando Gatekeepers ou serviços baseados em IP Centrex
Para troca de rotas entre o acesso e a IP-VPN serão suportados roteamento estático, eBGP, e RIPv2. Não
serão suportados os demais protocolos de roteamento (RIPv1, IS-IS, OSPFv1, OSPFv2, EIGRP).
3.1. MODELOS DE CPE:

Para acessos sem QoS, os modelos de roteadores / modem-router (acessos ADSL) atualmente utilizados
poderão ser adotados sem maiores restrições.
Para acessos ADSL com QoS, deverá ser utilizado o modelo Cisco 827. Este modelo provavelmente
poderá ser utilizado para grande parte dos acessos. A principal restrição envolvendo este equipamento é a
impossibilidade de classificação adequada de pacotes de voz, para redes que utilizam diversos aplicativos
UDP e/ou RTP simultaneamente em um mesmo intervalo de portas UDP. Para estes acessos ADSL ou
acessos Frame Relay / TDM com QoS, deverão ser utilizados CPEs Cisco 1700, 2600 ou 3600 e a
classificação deverá ser baseada na funcionalidade NBAR.

Posteriormente, CPEs de outros fornecedores poderão ser adotados para o atendimento do serviço Vetor,
desde que homologados para tal. Para o atendimento do Vetor, estes equipamentos deverão apresentar as
seguintes características para o atendimento deste serviço:
• Possibilidade de definição de 4 Classes de Serviço;
• Mecanismos de Classificação, podendo ser combinados, baseados em:
Ø Endereço IP de Origem / Destino;
Ø Porta TCP / UDP de Origem / Destino;
Ø Protocolos (p.ex. http, ftp e RT P/RTCP);
Ø Pacotes RTP baseado no campo Payload Type, conforme RFC1889;
• Mecanismos de Priorização por CoS, abaixo ou equivalentes:
Ø WFQ (Weighted Fair Queuing) ou WRR (Weighted Round Robin);
Ø LLQ (Low Latency Queuing) ou Strict Priority;
• Fragmentação em Layer 2:
o FRF.12 (Frame Relay Fragmentation Implementation Agreement);
o MP-RFC 1990 (The PPP Multilink Protocol) para FR e PPP.
• Buffer para armazenamento de pacotes em caso de congestionamento, com possibilidade de
controle do dimensionamento por Classe de Serviço;
• Ferramentas para monitoração de latência e jitter (p. ex. Cisco Service Assurance Agent ou
Lucent Quality of Service Management).
Estes requisitos não se aplicam para acessos utilizando IPSec, para requisitos de CPE para esta forma de
acesso, vide o Capítulo 9 – IPSec.
A configuração do CPE deverá ser detalhada para cada modelo adquirido. Este item é de extrema
importância pela estratégia adotada, onde o CPE será o principal elemento de controle de QoS para cada
acesso. No Anexo I é detalhado o procedimento de configuração para o serviço Vetor para o modelo
Cisco 827.

4. Agregador Multisserviços (Juniper ERX)

O Agregador possuirá a função de PE (Provider Edge) na IP-VPN.
Este equipamento será responsável pelas seguintes funcionalidades:
Ø Acessos:
• xDSL através de PVCs ATM dedicados;
• RAS (DialNet) através de túneis L2TP;
• IPSec (CPEs e SW Client Microsoft);
Ø Portal (ERX associado ao SDX).
Os acessos ADSL chegarão ao equipamento através das conexões STM-1 ATM conectadas aos BPX de
cada estação (duas conexões para a Rede xDSL).
Devido a restrições envolvendo QoS (fragmentação / interleaving), o agregador não deverá ser utilizado
para acessos Frame Relay e ATM, estes acessos deverão ser através de roteadores de acesso (Cisco
7500/7600).
Os dados entre os agregadores serão transmitidos sobre MPLS, com os túneis sendo formados utilizando
LDP e MP-BGP. .
Será necessário que o agregador faça a classificação, marcação e policing dos pacotes IP, e se possível, o
mapeamento para as células ATM (CLP).
O QoS no ERX será baseado nas classificações realizadas no CPE (quanto o CPE for da BrT), utilizando
somente o campo DSCP. Caso o CPE não seja da Brasil Telecom, será necessário que os pacotes IP
sejam classificados e marcados.
As marcações IP no DSCP serão mapeadas no campo EXP (MPLS) conforme tabela abaixo:
Classes de Serviço Valores de EXP
(CS) DSCP (IP) (MPLS)
Voz EF PHB 101 110 101
Multimídia AF41 PHB 100 010 100
Dados Expressos AF21 PHB 010 010 010
Dados DF PHB 000 000 000

Deverão ser definidos os seguintes Virtual Routers:

1. Virtual Router Local, destinado EXCLUSIVAMENTE para clientes com Vetor e DialNet Básico
utilizando somente um ERX, não necessitando troca de rotas via MP-BGP;
2. Virtual Router Default, destinado para tráfego de gerência (SNMP, telnet/ssh, ftp/tftp), sinalização
dos protocolos de roteamento e controle, AAA (RADIUS), acesso ao Portal, túneis IPSec e L2TP
proveniente de outras operadoras. Associados a este Virtual Router, estarão configurados as VRF de
todos os clientes IP-VPN com abrangência maior que um PE (Provider Edge).
ERX
RAS
Rede IP/MPLS
BrT
Túneis L2TP
LSP
VRFs Vetor
(Inter- regionais)
Comunicam- se
com outros PEs
VR Local VR Default
ERX
VRFs Vetor (Locais) VR DialNet VRF DialNet
Presente somente neste ERX Básico Intranet
A figura acima ilustra o cenário previsto, incluindo o atendimento de clientes DialNet.

Inicialmente, somente o Virtual Router Default (2) será utilizado para suporte a VPNs.
Durante o processo de autorização de sessões PPPoA, será necessário que o ERX receba do RADIUS
Server a rota estática associada ao acesso, isto será realizado utilizando o atributo 26-34 (Framed-IP-
RouteTag), esta informação deverá ser configurada no RADIUS Server durante a ativação do serviço e
para CPEs funcionando como DHCP Server, estes endereços IP deverão ser transmitidos através de IPCP
ao modem também.
Posteriormente, o ERX formará túneis LSP com os demais Ps e PEs da Rede MPLS (Cisco 7513, 7507,
7609 e GSR12410) utilizando LDP. As tabelas de roteamento das VPNs serão formadas utilizando MP-
BGP, comunicando-se com os Route Reflectors a serem instalados nas maiores localidades.

5. Roteadores de Acesso (Cisco 7500 / 7600)

Os Roteadores de Acesso deverão ser utilizados para acessos baseados em TDM, Frame Relay e ATM.
Roteadores que forem utilizados para acessos Vetor (IP-VPN) todos os módulos VIPs deverão ser
adequados para permitir acessos para este serviço através de qualquer interface.
Acessos TDM deverão utilizar Fra me Relay como protocolo de camada de enlace (OSI - Layer 2) para
utilização de FRF.12 para acessos de baixa velocidade.
Estes acessos possuirão as seguintes características:
Ø Para acessos com banda menor ou igual a 768kbps com QoS, será necessário:
v Funcionalidade de fragmentação em Layer 2:
• FRF.12 para acessos Frame Relay – Frame Relay, sejam através da Rede FR/ATM ou sejam
através de acessos através da Rede Determinística;
• LFI (Link Fragmentation and Interleaving) / PPP-ML para acessos Frame Relay (CPE) –
ATM ou ATM – ATM.
v Não deverá ser habilitado WRED
v Não deverá existir buffer para CoS Voz
Ø Para acessos com banda de acesso superior a 768kbps:
v Funcionalidades envolvendo fragmentação não deverão ser ativadas;
v WRED deverá ser habilitado para CoS Dados Expressos e Dados

6. Rede Frame Relay / ATM

Acessos Frame Relay deverão ser encaminhados para os equipamentos Cisco 7500 / 7600, enquanto os
acessos ADSL deverão ser encaminhados para os Juniper ERX.
Devido à falta de integração com as plataformas de aprovisionamento, serão configurados PVCs entre os
DSLAMs e Agregadores, utilizando VBR-nrt, conforme os acessos sejam comercializados. Para o caso
de DSLAMs em “cascata”, é importante notar que o PVC deverá ser configurado em todos os DSLAMs
envolvidos.
Estes circuitos deverão possuir as seguintes características:
As classes de serviço “Voz”, “Multimídia” e “Dados Expressos” deverão ser incluídas dentro de SCR
(Sustained Cell Rate), enquanto a classe de serviço “Dados” deverá ser considerada juntamente com as
demais classes para cálculo de PCR (Peak Cell Rate). É importante notar que alguns equipamentos
utilizam os parâmetros SCR, PCR e MBR (Maximum Burst Rate) com a unidade em “células / seg.”,
enquanto outros já utilizam estes valores em “bits / seg.”, onde será necessário recalcular os valores a
serem configurados.
Para conversão de bps (bits / seg) para cps (células / seg) deverá ser utilizada a seguinte fórmula:
TAXA (em bps) = 384 x TAXA (em cps)
Para garantir que seja dado o mesmo tratamento “best effort” na Rede ATM tanto para a Classe de
Serviço “Dados” e os dados de clientes com acesso a Internet (ADSL Turbo), será necessário que o
DLSAM faça a marcação de todas as células pertencentes ao VP associado a estes serviços, conforme a
figura abaixo.
Além da marcação de células, o tráfego Interntet deverá ser marcado nos DSLAM com CLP=1. Em
DSLAM Lucent Stinger, deverá ser feito através de “Traffic Descriptor” adequados (noclp-tagging-noscr
com SCR=0). Em DSLAM Cisco, deverá ser configurado “globalmente” atm clp-drop force ubr on.
Voz + Multimídia => CLP=0

Dados exp. + Dados => CLP=1
(OPCIONAL)
Todas células não marcadas,

CPE VETOR CLP=0 ERX
DSLAM
BPX/IGX BPX
MGX (DSL)
CPE TURBO Internet 6400
(Internet) PVP => CLP=1
CLP=0
PVP => CLP=1

Marcação na NSP ou na NRP

Para comunicação entre ERXs, deverão ser configurados PVCs ATM VBR-nrt, estes PVCs serão
utilizados posteriormente como backup tunnels. A interface entre o ERX e o BPX deverá ser configurada
como NNI. A alocação de VPI, VCI poderá ser realizada da seguinte forma:
VPI: Código de Área do DSLAM (61 – BSA, 41 – CTA, 51 – PAE, etc)
VCI: # Seqüencial (número seqüencial)
O PVC de acesso, entre o Modem xDSL e o DSLAM poderá permanecer com os valores atuais (VPI:0,
VCI:35), enquanto para o PVC interno, entre o DSLAM e a Rede ATM, deverão ser utilizados VPI=241-
247 (sendo um alocado para cada DSLAM em cascata, iniciando em 247 para o DSLAM mais próximo
do BRAS), conforme documento do Serviço InterLan, a alocação de VCI será seqüencial e controlada
pela Operação.
DSLAM-4
VP=245
DSLAM-2
VP=246
DSLAM-5
VP=244
DSLAM-1 BPX
VP=247
DSLAM-6
VP=242
DSLAM-3
VP=243
DSLAM-7
VP=241
O plano de numeração de VPI/VCI entre a Rede ATM e o ERX deverá ser baseado na mesma política
utilizada para os acessos IP Light / Dedicado existentes na Rede IP BrT:
VPI= Porta (Interface do ERX)
VCI = # seqüencial.

7. Rede DT e SDH
A rede Determinística (DT) também pode ser usada para prover a conexão entre os roteadores de
distribuição e acesso até o roteador do cliente. Com essa topologia pode ser atendidos clientes vetor sem
a necessidade de passar pela rede Frame Relay ou ATM. O protoloco utilizado será o Frame Relay por
vários motivos. Um dos motivos é a necessidade de se utilizar FRF.12 para QoS de VoIP e para
multiplexação de circuitos lógicos dentro do mesmo enlace. A figura abaixo mostra a topologia, uma
delas seria o roteador de distribuição ligado direto na rede DT através de STM-1 canalizado/estruturado e
a outra ele ligado na rede SDH através de E1 ou STM-1 estruturado.
8. Acesso vetor para múltiplos de E1
Caso o cliente requeira velocidades múltiplas de 2Mbps (nxE1 até 8Mbps), deverá ser utilizado MLPPP e
um roteador de distribuição como PE para terminar a conexão lógica do cliente. Essa conexão para o
roteador de distribuição deverá ser tipo E1 serial ou STM-x canalizada/estruturada, uma vez que o
protocolo MLPPP garante agregação de vários E1 somente nessa topologia (serial-serial). A figura abaixo
ilustra essa topologia:

9. Rede IP / MPLS
Inicialmente, a conexão entre o ERX e a Rede IP BrT será utilizada para:
Ø Gerência do elemento de rede (NMC-RX - Agregador)
Ø Gerência das VPNs
Ø Autenticação via RADIUS
Ø Autorização através de COPS associados à base de dados LDAP
Ø Conexões IPSec
Ø Acesso L2TP (Layer 2 Tunnel Protocol )
Após a implantação de MPLS (QoS e VPN) baseado nos roteadores Cisco (7500, 7600 e GSR12410) e
dos Route Reflectors para MPLS-VPN, a comunicação (dados, protocolos de controle e LDP, OSPF,
BGP e MP-BGP) entre os elementos pertencentes à Rede IP e o ERX será através da interface GbEth.
No Route Reflector deverá ser configurado o limite máximo de rotas para cada VPN, através do
comando: maximum routes <max-thresh> <mid-thresh (% of max)>, dentro de ip vrf [vrf-name], este
número deverá ser, por default, configurado em 500 rotas e um threshold de 80 %, para redes
corporativas de maior porte, este número poderá ser aumentado sob demanda.
MPLS-QoS será baseada somente sobre e-LSP (DiffServ), não será utilizado IntServ (RSVP). Para
atendimento adequado das classes de serviço comercializadas deverá ser acompanhado o volume de
tráfego que estará sendo utilizado em cada classe e os níveis de SLA apresentados pela Rede IP/MPLS,
através dos Shadow Routers existentes (perda de pacotes, latência e jitter).

10. Acesso Remoto

Acessos remotos são considerados os acessos que não possuam recursos de acesso dedicados (par
metálico, circuitos dedicados da Rede de Dados). Estes acessos permitem que o cliente estabeleça
conexão dinamicamente e a partir de diferentes acessos físicos e / ou terminais.
10.1. DialNet (RAS)

Para o atendimento de clientes que necessitem de acesso remotos via Dial-Up (DialNet), a solução será
similar para clientes DialNet Básico / Intranet e Vetor.
Basicamente, todas as sessões destes clientes serão encaminhadas utilizando túneis L2TP (Layer Two
Tunnel Protocol). Estes túneis serão formados entre o RAS (com a função de LAC) até o ERX (LNS) em
que a principal estação do cliente (“hub”) estiver acessando.
No ERX, túneis L2TP serão terminados no VR Default, no módulo para túneis L2TP (LNS) e as sessões
PPP serão terminadas na VRF do cliente.
CyDC
RADIUS Authent
BrT
1. Authentication -request
user@vetorii
3. Authentication -request
user (p/ Server IP1’)
NAT
2. Authentication-request
user (p/ Server IP1 )
IP1
IP1’
(pub)
(priv)
L2TP
LAC LNS
RADIUS Authent.
VetorII Cliente
PPP VRF
Default
Virtual Router
TSM (ERX)
Para clientes do serviço DialNet Básico, será necessária ainda a configuração de um PVC até o ERX mais
próximo, este PVC deverá ser dimensionado conforme o número de portas Dial contratadas e
configurado o(s) RADIUS Server do cliente. Deverá ser utilizado o mesmo dimensionamento utilizado
atualmente (8kbps / porta).
Maiores detalhes de configuração e requisitos necessários poderão ser encontrados no documento de
arquitetura de prestação do serviço DialNet Básico / Intranet.

10.2. IPSec
Todos acessos IPSec serão concentrados no Juniper ERX. Nesta forma de acesso, independente da
modalidade utilizada (CPE -based ou Client-based), não existirá suporte a nenhum mecanismo de QoS.
Esta funcionalidade será suportada para o Serviço Vetor somente para acessos conectados à Internet.
Clientes que desejem utilizar IPSec dentro de sua IP-VPN, deverá ser recomendada a utilização de
sessões IPSec fim-a-fim (cliente-servidor) para terminais e/ou aplicações específicas.
Estão previstas duas formas de acesso utilizando IPSec:
• CPE-based, onde a sessão IPSec é formada entre o CPE no site do cliente e o Agregador
Multisserviços, destinado a acessos via Internet, principalmente fora da Área II.
• Client-based, onde a sessão IPSec é estabelecida entre um Client IPSec (Microsoft) do
computador do cliente até o Agregador. Paraeste caso, o cliente poderá estar utilizando qualquer
acesso público para conectar-se a sua IP-VPN.
Os CPEs a serem utilizados para acessos IPSec deverão possuir as seguintes características:
• Endereço IP público fixo, ou seja, sem a presença de NAT entre o ERX e o CPE do cliente;
• ESP (Encapsulating Security Payload – RFC 2406)
• ESP-3DES (Data Encryption Standard)
• ESP-SHA (Secure Hash Algorithm)
• IKE (Internet Key Exchange – RFC 2409), baseado em pre-shared key
Inicialmente, será suportada somente criptografia baseada em ESP, utilizando 3DES e SHA. A troca de
chaves será baseada em IKE. Devido às restrições envolvendo o equipamento, cada cliente deverá utilizar
uma chave comum para todos os acessos envolvidos.
Para sessões IPSec Client -based, será estabelecida uma sessão IPSec associada a uma sessão PPP-L2TP,
conforme a figura abaixo. Todas as funcionalidades associadas à pilha de protocolos (stack ) no cliente
serão realizadas pelo Microsoft L2TP/IPSec VPN Client. Após o estabelecimento da conexão IPSec, uma
sessão PPP deverá ser autenticada, via RADIUS, do usuário em uma base de dados do cliente. O modelo
de prestação de serviço baseado em limitação de sessões simultâneas por parte do cliente será limitada
baseada em restrição no Pool de endereços IP disponíveis para acessos IPSec. Neste caso, é importante
notar que todo o processo de autenticação do cliente será realizado e somente após a autenticação do
cliente a sessão apresentará falha e o usuário não será capaz de utilizar o acesso IPSec.
Portanto, cada sessão IPSec Client-based consumirá três sessões IP no ERX.
Com o uso desta solução, conexões discadas a Internet apresentarão um cabeçalho extenso e
processamento intenso de pacotes no computador do cliente, o desempenho da conexão poderá ser
insatisfatório.
IP Privado (VPN)
PPP
L2TP
IPSec
IP Público (iNET)
PPP
LAC L2TP LNS
IPSec
Cisco GSR
CPE
VRF
Rede IP IP-VPN
Internet
BrT (MPLS)
I/O ISM TSM
Juniper ERX

Maiores detalhes sobre o procedimento de configuração do IPSec, consultar o anexo III.
11. RADIUS / LDAP / SDX

Está sendo previsto o cenário utilizando RADIUS Authentication / Authorization para acessos xDSL,
com PPPoA: não existirá Proxy RADIUS, toda a base de dados, incluindo VPN, QoS associado,
Endereço da Rede LAN, etc estará armazenada no LDAP Server e será enviada ao ERX durante o
processo de Autorização pelo RADIUS Server da Brasil Telecom, demais variáveis poderão ser
solicitadas posteriormente pelo SDX para o LDAP (p. ex. alteração em políticas de CoS).
Inicialmente, serão utilizados servidores Cisco Access Registrar dedicados para autenticação /
autorização do Serviço Vetor, com as informações armazenadas no LDAP junto ao SDX. Desta forma,
todas as informações associadas ao acesso xDSL estarão armazenadas no LDAP Server. A configuração
no LDAP poderá ser feita de forma centralizada ou não, mas a base de dados deverá ser centralizada,
permitindo melhor administração da base de dados e da plataforma.
Para serviços a serem bilhetados, serão necessárias a implantação e adequação da Rede IP, onde deverão
ser contemplados novos Servidores RADIUS para Accounting, implantação da rede de sincronismo
(Time -of-Day), previstos no Projeto IPDR.
LDAP: estamos aguardando retorno sobre as funcionalidades associadas às questões enviadas a Siemens
para melhor definição da estrutura de LDAP na Rede e no serviço Vetor. Esta base de dados armazenará
informações relativas somente a acessos através de PPPoA, as demais formas de acesso (ATM, FR,
TDM). Algumas considerações deverão ser:
Ø Durante a autenticação da sessão PPPoA, deverão ser enviados diversos parâmetros ao ERX:
• Framed-IP-Address e Framed-IP-Netmask: Bloco de Endereços IP a serem utilizados pelo
DHCP Server;
• Framed-IP-Route-Tag: Adiciona rota no ERX;
• ATM-Service-Category, ATM-SCR, ATM-PCR, ATM-MBS: Parâmetros para PVC ATM;
• QoS-Profile-Name: Perfil de QoS associado ao acesso;
• VPN a qual o cliente pertence

12. Gerência
A gerência das VPNs será através de uma VPN dedicada a gerenciamento, esta VPN não será definida no
ERX, com o objetivo de evitar NAT, que será feito em roteador dedicado ou Firewall, utilizando a
mesma infra-estrutura que está sendo elaborada para o Serviço VIP Report, conforme figura abaixo.
CyDC
Route e-Health HP OV
Reflector Collector Poller
NAT no VIP Router

MP-BGP
VIP
7500 Router
FEth FEth
CE
FW
MPLS
ERX
CE
ERX
7500
CE
CE
Neste cenário, cada VPN é estendida ao “VIP Router” (que terá de função de PE em MPLS-VPN) que é
responsável pelo NAT e o Firewall é responsável apenas pelos aspectos de segurança.
O plano de endereçamento IP deverá seguir o plano de endereçamento previsto para o Serviço VIP. Uma
possibilidade de limitar a tabela de roteamento no “VIP Router” é utilizando filtro para importar /
exportar rotas baseadas em máscara /32, neste caso somente endereços de Loopback seriam conhecidos
pelo “VIP Router”.
As regras de segurança (access lists e regras de firewall) a serem definidas para as VPNs MPLS deverão
mais rigorosas que as regras previstas aos demais serviços VIP, pois, em caso de nenhuma política de
restrição seja adotada, a partir do “VIP Router” será possível acessar qualquer rede do cliente (servidores,
hosts, roteadores, switches).
Maiores detalhes a respeito do atendimento deste serviço poderão ser encontrados no documento de
Arquitetura do VIP Report.
Deverão ser elaborados procedimentos e regras de segurança com o objetivo de garantir a segunça das
VPNs.

13. Quality of Service (QoS)

O Serviço Vetor possui quatro Classes de Serviço previstas (Voz, Multimídia, Dados Expressos e
Dados). Para cada uma destas classes é previsto um tratamento diferente ao longo de toda a Rede IP BrT .
O modelo de QoS adotado está baseado em DiffServ. A classificação e marcação de DSCP dos pacotes
IP será realizada pelos CPEs, e a marcação de EXP dos pacotes MPLS será feita pelos PEs envolvidos. A
partir destas marcações serão realizadas as classificações em filas em cada roteador da Rede IP BrT.
Cada fila está associada a uma Classe de Serviço (CoS), onde serão definidas características de prioridade
para transmissão (WFQ, WRR), tamanho da fila (buffer), políticas de controle de fluxo (WRED). A
tabela abaixo apresenta os mecanismos de QoS envolvidos para cada um dos elementos de rede
envolvidos.
CPE Juniper ERX Cisco 7500 Cisco GSR 12410
TCP / UDP / IP
Classification DSCP (IP) DSCP (IP) EXP (MPLS)
NBAR *
Marking ACL → DSCP DSCP → EXP DSCP → EXP -
Voice Queuing LLQ Strict Priority LLQ ATM: Strict
POS/GE: Alternate
Queuing Serving CB-WFQ WRR per-VC CB-WFQ MDRR
TCP Friendly Discard
Rate Limiting WRED DWRED WRED
One-Rate / WRED
Layer 2 (FR/ATM) DSCP → DE / CLP - DSCP → DE / CLP -
ATM CoS VBR-nrt UBR VBR-nrt -
* – Somente para equipamentos Cisco Series 1700, 2600, 3600 e 7200
Inicialmente, para simplificação do modelo de QoS, todas as políticas aplicadas estarão voltadas para
mecanismos de controle de saída (egress) das interfaces, sem controle de admissão para entrada de dados.
Para o atendimento de IP QoS, deverão ser elaboradas pré-configurações default para acessos de
256kbps, 512kbps e 2Mbps. Estas pré-configurações consideram determinadas premissas que são
apresentadas na tabela abaixo. Para alterações e/ou ajustes de parâmetros, foi elaborada uma planilha que
calcula os valores dos parâmetros de configuração de todos os elementos de rede envolvidos.
Acesso Canais de Voz Dados Expressos
256 kbps 0, 2, 4 128 kbps
512 kbps 0, 4, 8 256 kbps
2 Mbps 0, 15 e 30 (E1) 1 Mbps
CODEC Voz G.729 (8 kbps), 20ms de sampling

BW (Dados) BW (Acesso) – BW (Voz) – BW (Dados Exp.)
Multimídia Zero (não previsto)
Premissas para pré -configurações default
A partir da configuração default e de coleta de informações sobre o tráfego de cada acesso, a

configuração poderá ser ajustada com a ajuda de uma planilha que determina os valores mais adequados
para o cliente.
NOTAS:
Ø Caso o cliente implante / migre aplicativos ou altere o interesse de tráfego (p. ex. remanejamento de
servidores) dentro da IP-VPN, poderá ser necessária a reconfiguração dos parâmetros de QoS dos
acessos envolvidos.
Ø Os parâmetros de QoS para CoS Dados e Dados Expresso são assimétricos pois a grande maioria
dos aplicativos existentes são baseados em servidores e o tráfego (volume de dados e tamanho médio
de pacotes) são distintos no sentido Server→Client e Client→Server.

14. Extranets para acesso a serviços de valor adicionado

(conteúdo)
Extranets são redes de determinados clientes que podem compartilhar ni formações com outras redes
corporativas. Por exemplo, empresas de cartão de crédito, ASPs (Application Service Providers), bancos
ou qualquer outro provedor de conteúdo podem permitir o acesso a determinados servidores a partir de
outras redes corporativas.
A arquitetura genérica para atendimento do Serviço Vetor de acesso a conteúdos (denominado pela área
comercial da BrT de CardConnect) é apresentada na figura abaixo.
Cliente 1
Loja z
Cliente 1 Acesso
Loja x Vetor
Cliente 1 FR
Matriz
Acesso
Vetor Host
xDSL Acesso Conteúdo A
Vetor FR
Rede ATM / FR
Cliente 3 VPN
Loja j Cliente 2
Acesso
Acessos VPN Vetor FR
Interlan VPN Conteúdo A
Cliente 3
Loja k FR Cliente 1 PE X-25
Acesso
Vetor FR Host
Rede IP / MPLS VPN VPN
Conteúdo B
Cliente 3 Conteúdo B
Cliente 3
Loja l
Acesso
Interlan L2TP
xDSL
RTPC
Switch
ATM
Acesso
Interlan
FR
DSLAM Acesso Internet

Túnel IP Sec Cliente 3
Cliente 3 ADSL
Criptogr. 3DES Pública Acesso Discado
Concentrador
Roteador de Acesso
à Internet Cliente 3
Consultor em Trânsito
RAS
Cada provedor de conteúdo terá sua própria VPN MPLS na rede Vetor. A conectividade entre as VPNs
de clientes corporativos e a VPN do conteúdo será realizada através de uma implementação de NAT entre
cliente e provedor de conteúdo.
O(s) pool(s) de endereços IP para a função NAT deverá ser definido pelo provedor de conteúdo para que
seja assegurado que não haverá conflito de endereçamento após a realização do NAT. Alternativamente,
poderá ser utilizado NAT Overload.
O(s) servidor(es) de conteúdo serão conhecidos com endereço IP público, designado e controlado pelo
provedor de conteúdo e alternativamente pela Brasil Telecom. Deverá ser importada uma rota de host
(/32) para cada um deste(s) endereço(s) de servidor(es) nas VRFs de clientes corporativos. Em cada CE,
deverá existir uma rota estática para estes endereços de host (/32).
Deve ser implementada política de segurança no CE que restrinja o acesso apenas ao(s) servidor(es) de
conteúdo.
A função de NAT entre VRFs será realizada através de um firewall externo ao roteador PE. Neste caso,
deve existir um firewall dedicado, por centro de roteamento, para esta função. O firewall externo e o
roteador PE estarão conectados via interface GigaEthernet configurada como trunk 802.1q. As VRFs
corporativas serão conectadas às VRFs de conteúdo por meio de VLANs, conforme figura abaixo.

Para garantir a disponibilidade do serviço, a função de NAT deve ser realizada através de firewalls
redundantes.
O Firewall Externo deverá suportar a funcionalidade de Virtual Context (Cisco) ou Virtual Systems
(Juniper). O número de VLANs suportadas deve ser pelo menos 2 (duas) vezes o número máximo de
contextos virtuais do firewall.
Alguns detalhes dessa implementação com relação à alocação de endereços IP de cada entidade:
• Deverá ser alocado pelo cliente que acessa o provedor de conteúdo um endereço IP com máscara
/30, independentemente dos números de pontos que eventualmente o cliente possua na rede
Vetor.
• Deverá ser alocado pelo Provedor de Conteúdo um endereço IP público de máscara de host para
representar o endereço IP do servidor do provedor de conteúdo.
Em caso de conflito entre o endereço IP privado fornecido pelo cliente e provedor de conteúdo para
interligação do Firewall, o cliente deverá escolher uma outra faixa de endereços não conflitante.
Para exemplificar, vamos criar um caso hipotético, onde um provedor de conteúdo possui 3 clientes na
rede Vetor. Para implementar essa solução seriam gastos:
• Endereços privados fornecidos pelos clientes 3x /30

• Endereço público fornecidos pelo provedor 1x/32

• Endereços privados fornecidos pelo provedor de conteúdo: 3x /30 + 3x /32(caso não seja
adotado NAT Overload)
Uma outra vantagem dessa solução é que é possível aplicar outras políticas de segurança em cada
interface de acesso tanto de entrada como de saída sob o ponto de vista do cliente ou provedor de
conteúdo, uma vez que é utilizado um Firewall.
Solução VISANET
A solução CardConnect para atendimento à rede VISANET está descrita no Anexo V. Esta solução foi
desenhada especificamente para atender as especificações da VISANET para redes de acesso Wireline IP
para soluções de TEF e aplica-se estritamente ao atendimento da VISANET.
A solução VISANET possui as seguintes características/limitações:
• O uso da funcionalidade NAT (Network Address Translation) minimiza a possibilidade de
ocorrência de conflito de endereço IP, mas não consegue evitar a ocorrência deste conflito em
100% dos casos, principalmente para um número grande de acessos. Existe um risco de conflito
de endereçamento IP entre os endereços privados alocados para os links WAN da topologia e os
endereços IP do segmento LAN do estabelecimento comercial.
• Em função do exposto no item anterior, o controle de alocação de endereços IP é crítico para
minimizar a probabilidade de conflitos de endereçamento e, por conseqüência, o não
funcionamento do serviço.
• Pelo uso extensivo de configurações manuais de NAT e filtro de pacotes (ACLs), a solução é
propensa a erros humanos e não escala para uma grande quantidade de acessos.
Em função das limitações acima, deverá ser realizado um estudo de migração do atendimento da rede
VISANET para a solução definitiva com uso de firewall externo, descrita neste documento.
15. Interconexão (VPN Inter-AS)

Para o atendimento de IP -VPNs com outras operadoras, a proposta inicial de interconexão será baseada
no modelo proposto pela Cisco como “VPN back-to-back”, onde cada operadora forma a VPN do cliente
e as rotas de endereços IP do cliente é trocada através de uma sessão eBGP entre (sub)interfaces
dedicadas a VPN do cliente.
Evidentemente, o modelo a ser adotado dependerá de acordos bilaterias com as outras operadoras.
Neste modelo, a rede de cada operadora opera de forma independente e a troca das rotas da VPN de
clientes é realizada considerando a outra VPN como um acesso (uma conexão PE-CE).
A figura abaixo ilustra o modelo descrito.
VRF Cliente
CPE CPE
Cliente Cliente
eBGP
PVC
Rede IP Frame Relay Operadora
BrT PE
CPE PE CPE
Cliente Cliente

Este modelo apresenta restrições com relação a escalabilidade pela necessidade de configuração de sub-
interfaces. Caso exista uma ampliação de interconexão com alguma operadora para atendimento superior
a 50 VRFs, este modelo será reavaliado para a possibilidade de substituição por uma interconexão
baseada em MP-eBGP ou OSPF-TE.
16. Multicast para MPLS/VPN
O Multicast para redes MPLS/VPN não é um protocolo padronizado na época em que se escreve esse
documento. Por demanda de Marketing, e dado que a rede é composta basicamente por dois fornecedores
de elementos da rede IP, foi seguido um draft chamado de “draft-rosen-vpn-mcast-06.txt” que está
disponível para as plataformas Cisco (10K, 7600 e GSR) como para as plataformas Juniper (ERX e M-
40).
Funcionalidade do Multicast, ponto de vista do cliente
Aspectos do protocolo
O Multicast será suportado nas versões IPv4 através do protocolo IGMPv2. Não será suportado IGMPv3
nesse momento. O cliente poderá utilizar quaisquer endereços de Multicast dentro da sua VPN.
Opções de topologia
Não será suportado Multicast em VPN formadas através do IPSEC (tanto no mo dos cliente como CPE
based). O Multicast será suportado tanto para acesssos ADSL como Frame Relay.
Aspectos de QoS
O tráfego de Multicast poderá ser classificado nas classes de Multimídia, Dados Expressos e Dados
Comum (Best Effort) e não poderá ser classificado como VoIP.
Aspectos de LAN
O cliente não precisa habilitar nada na sua LAN. Os quadros de multicast são encaminhados normalmente
na LAN do cliente através de um endereço destino de multicast ou broadcast. Não será suportado nenhum
protocolo específico de Multicast para LAN como o CGMP( proprietário da Cisco).
Gerência

Não existirá uma gerência específica de tráfego Multicast, a menos que algum tráfego de Multicast seja
classificado por Dados Expressos ou Multimídia.
Funcionalidade do Multicast, ponto de vista do Backbone IP
Todo tráfego de Multicast será recebido através de um CE e encaminhado para os outros CE ou através
túneis entre PE (MTI – Multicast Tunnel Interface) ou diretamente aos outros CE. Todo tráfego de
Multicast será replicado a medida que a árvore do MDT (Multicast Domain Tree) for se ramificando. A
única limitação é que um tráfego de Multicast é enviado para todos os PEs, mesmo aqueles que não
possuem receptores para aquele grupo.
Quando o tráfego de Multicast é encaminhado dentro do Core da rede, ele é tratado como um tráfego de
Multicast normal. Isso quer dizer que o backbone tem que estar preparado para suportar esse tráfego. A
figura abaixo ilustra do funcionamento do Multicast para MPLS/VPN.
Serão utilizados os seguintes protocolos para suportar essa funcionalidade dentro da rede da
BrasilTelecom: PIM SM, IGMPv2, RP estático para a o RP do cliente e BSR para o RP da rede.
Parâmetros alocados

Cada cliente utilizará um endereço de Multicast único na rede Core. Esse endereço é utilizado pela
interfaces MTI. Esse endereço de Multicast deverá ser alocado exclusivamente para um cliente e
unicamente para a rede. Segue as faixas de endereços definidas pelo IANA:
Descrição Faixa
Endereços locais reservados 224.0.0.0/24
Endereços para Multicast globais 224.0.1.0 to 238.255.255.255
Source Specific Multicast 232.0.0.0/8
GLOP Addresses (endereços formados pelo AS 233.0.0.0/8
Number)
Endereços Administrativos 239.0.0.0/8
Traduzindo, apenas endereços IP da faixa 239.0.0.0/8 poderão ser alocados nesse momento.
Uma vez alocado o valor do IP do Multicast dentro do backbone para o cliente. Ele deverá ser utilizado para
configurar as VRF do cliente nos Cisco e o túnel MTI no ERX dentro do virtual router da VPN.

17. Anexo I: Configuração de CPEs

Para configuração adequada do equipamento, será necessária a configuração dos seguintes itens:
Ø Interface / Sub-interface ATM (ADSL)
• Encapsulamento AAL5
• VPI / VCI
• Características de Tráfego (VBR- nrt, PCR, SCR, MBS)
Ø Interface Dialer (PPPoA)
• Username@domain / password
• Política de QoS associada à saída (output) para Priorização (CBWFQ, LLQ e WRED)
Ø Interface Ethernet
• Endereço IP / Máscara
• Política de QoS associada à entrada (input) para Classificação e Marcação de DSCP
Ø Interface Loopback
•
Ø Protocolo de Roteamento
• Rota estática / RIPv2 / eBGP
Ø Listas de Acesso (ACL)
• Uma lista de acesso para cada CoS contratada pelo cliente
• Necessárias para classificação de pacotes, tanto para entrada quanto para saída.
• Eventuais solicitações de filtros pelo cliente
Ø QoS (Quality of Service)
Ø Políticas de Classificação (por lista de acesso)
Ø Marcação: DSCP Setting
Ø CBWFQ (Class Based, Weighted Fair Queueing)
Ø WRED (Weighted Random Early Discard)
Ø LLQ (Low Latency Queueing)
Ø SAA (Service Assurance Agent – Clientes VIP Report)

18. Anexo II: Mapeamento de Aplicativos

Este capítulo apresenta a estratégia de classificação de pacotes, onde os pacotes serão classificados
baseados nos aplicativos utilizados pelos clientes da Brasil Telecom.
A política de classificação será a mesma para todos os clientes, onde as regras serão adicionadas sob
requisição do cliente. A tabela abaixo apresenta os aplicativos conforme solicitação da DNCC, à medida
que outras aplicações sejam solicitadas, regras de mapeamento serão adicionadas.
Classe de Serviço Aplicativo Porta TCP Server Observação

a definir Em caso de multimedia conference, MCUs serão consideradas
Multimídia RTP / RTCP *
(UDP)* como server
a definir Em caso de troncos IP PBX, IP PBX serão consideradas como
Voz RTP / RTCP *
(UDP)* server
3300 ** Versões mais recentes de SAP utilizam JAVA client, a
SAP SIM
3001 ** classificação passa a ser baseada no End. IP do server
CADView-3D 649 SIM
PeopleSoft - SIM Aplicação baseada em Java client, idem SAP
66 (SQL*NET)
Oracle 1525 SIM Oracle Server
1571 Remote Database (rdb)
SQL Services 118 SIM
SQL-Net 150 SIM
Ingress 1524 SIM
1498 Sybase -SQL
Dados Expressos
Sybase 2439 SIM Sybase -DB-Sync
2638 Sybase -Anywhere
PostgreSQL 5432 SIM
e-Mail (POP3) 110 SIM Post Office Protocol - Version 3
e-Mail (SMTP) 25 SIM Simple Mail Transfer
telnet 23 SIM
Em caso de serviços de Intranet, estas portas deverão ser

http / https 80 / 443
priorizadas baseadas nos End. IP dos servidores. Sem
*
funcionalidades de reconhecimento de aplicativos, não será
ftp 21 possível identificar e priorizar tráfego http/https e ftp
(*) – Aplicações real-time baseadas em RTP/RTCP necessitarão que o cliente informe qual o intervalo de portas UDP que será utilizado
(**) – Utilização de portas não autorizadas pelo IANA
Além disso, SIP e H.323 são protocolos de sinalização utilizados por aplicativos de Voz e Multimídia,
estes pacotes deverão ser tratados como dados expressos.
Sinalização Descrição Protocolo Porta Observação
DNS Service TCP/UDP 53 DNS
SIP Messages TCP/UDP 5060
Messages TLS (TCP/UDP) 5061 Alternativa túnel
ILS Registration (LDAP) TCP 389
User Location Service TCP 522
T.120 TCP 1503
Gatekeeper Discovery TCP 1718
H.323
Gatekeeper RAS TCP 1719
H.323 Call Setup TCP 1720
Audio Call Control TCP 1731
H.245 Call Parameters UDP Dinâmica ≥ 1024

19. Anexo III: Configuração IPSEC (ERX e Cliente)

Este anexo descreve o procedimento de configuração de clientes IPSec utilizando como cliente um PC
rodando Windows XP (software IPSec built-in) e como servidor ou terminador do IPSec um ERX.
19.1. Requisitos do Sistema Operacional do cliente
• Windows XP com SP2. SP1 não suporta a funcionalidade de NAT Traversal (NAT-T).
19.2. Requisitos de Hardware e sistema Operacional do ERX

• ERX versão JunOS 6.0 ou superior ( versões 5.3 ou anteriores não suportam NAT -T)
• Placa de IPSEC
• Placa de tunnel
19.3. Parâmetros necessários antes de se configurar cliente

ou ERX
• Nome do usuário no formato ( nome@dominio )
• Senha do usuário no domínio definido acima.
• Endereço IP do servidor Radius que realizará a autenticação do cliente dentro da VPN do
mesmo.
• Chave de criptografia (gerada pela Brasil Telecom, número de caracteres mínimo de 20 e única
para o servidor IPSec Vetor).
• Pool de endereço IP que será utilizado pelos usuários remotos quando conectados na VPN
através do IPSec. O primeiro endereço IP desse pool é reservado para a loopback c onfigurada no
ERX dentro da vrf do cliente.
19.4. Procedimentos de configuração
Procedimento de configuração do Cliente
1. No Windows XP, adicionar uma nova conexão tipo conectar-se a uma rede privada pela Internet.
2. Configurar para não discar para Internet.
3. Na janela endereço destino, digitar o endereço IP da loopback do virtual-router empresarial do ERX
que é utilizado para terminar as conexões IPSec.
4. Na disponibilidade de conexão, fica a critério do usuário a definição de criar um acesso disponível
para todos ou somente o usuário corrente.
5. Digitar o nome da conexão e concluir.
6. Abrir a caixa de conexões da rede, clicar na conexão recém-criada e selecionar propriedades.
7. Nas opções de segurança, clicar em IPSEC, checar o pré-shared key e entrar com a chave pré-
definida.

8. Na aba de rede, campo de tipo de servidor de VPN, selecionar o L2TP.

9. Clicar em OK e concluir a configuração de propriedades.
Procedimento de configuração do ERX
No ERX, alguns passos somente são necessários para o primeiro cliente.
1. Primeiramente deve ser criada a vrf dentro do virtual-router empresarial utilizado os parâmetros e
procedimentos habituais.
2. Dentro do virtual-router empresarial:<nome da vrf> criar um pool de IP endereço:
ip local pool "pool_ipsec"

ip local pool "pool_ipsec" <segundo endereço IP da faixa> <ultimo endereço IP da faixa>
3. Criar a interface de loopback 0 dentro do empresarial:<nome da vrf> com o primeiro endereço IP da
faixa.
4. Ainda dentro do empresarial:<nome da vrf> configurar as instâncias de Radius Authentication
Server com os endereços IP providos pelo cliente.
5. Forçar a configuração aaa accounting ppp default radius dentro do empresarial:<nome da vrf>.
6. Dentro do virtual-router default configurar o domain-map da seguinte forma:
aaa domain-map <dominio do cliente, ex: emp resa.com.br>

router-name "empresarial:<nome da vrf>
address-pool-name "pool_ipsec"
ipv6-router-name default
7. Em seguida configurar o profile tunnelppp (caso não exista):
profile tunnelppp
ip unnumbered loopback 0
ip mtu 1400
ppp authentication pap chap
ppp mru 1400
8. Configurar o profile do ipsec (caso não exista)
ipsec transport profile securel2tp virtual-router empresarial ip address 0.0.0.0

transform-set esp-3des-hmac-sha esp-3des-hmac-md5 esp-des -hmac-md5 esp-des-
hmac-sha
local ip address <loopback do virtual-router empresarial>
pre -share -masked <chave do pre-shared key>
9. Configurar o profile do l2tp (caso não exista)
l2tp destination profile securetunnel virtual-router empresarial ip address 0.0.0.0

remote host default
profile tunnelppp
local ip address <loopback do virtual-router empresarial>
enable ipsec-transport
Comandos de troubleshooting:
Visualização das sessões PPP

Show subscribers
Visualização dos túneis IPSEC ativos:
Show ipsec transport interface detail
Visualização dos túneis L2TP ativos:
Show l2tp tunnel detail
20. Anexo IV: Configuração IPSEC (ERX e Netscreen)
20.1. Requisitos do Sistema Operacional do Netscreen
• NetscreenOS versão 5.0 ou superior.
20.2. Requisitos hardware e Sistema Operacional do ERX

• ERX versão JunOS 6.0 ou superior ( versões 5.3 ou anteriores não suportam NAT-T)
• Placa de IPSec
20.3. Requisitos e restrições da Rede
• O endereço IP ou nome do host utilizado pelo cliente para formação do túnel IPSec deve ser alcançável através de
qualquer ponto da Internet.
• O tamanho máximo de MTU do IP é reduzido para 1446 devido ao overhead do IPSec.
• Na criação do túnel IPSec, os mapeamentos entre redes IP que podem ser acessadas através do túnel são estáticos, logo
uma mudança de endereçamento na VPN do cliente pode requerer que haja uma mudança na configuração do Netscreen
e ERX na definição de redes locais e remotas.
20.4. Parâmetros necessários antes de se configurar o

Netscreen ou ERX
• Rede local (LAN do Netscreen)
• Redes remotas que serão acessadas através do tunel IPSec
• Endereço IP Fixo e válido que será utilizado no Netscreen.
• Pré-shared Key utilizada entre Netscreen e ERX
• Endereço IP do tunnel IPSec (/30) definido pelo cliente (deve ser um endereço alocado dentro
do plano de endereçamento do cliente)

20.5. Procedimentos de configuração
Procedimento de configuração do Netscreen
1. Se for necessário apagar toda configuração do NS utilizar os comandos:
• Unset all
• Reset (Não permitir salvar as configurações e confirmar)
2. Configuração de interfaces (trust, untrust e túnel)
A interface untrust é a interface cujo endereço IP é valido e está conectado a Internet e a interface trust está
conectada a LAN e tem endereço IP privado. A interface túnel tem o endereçamento IP alocado pelo cliente,
será o endereço IP da WAN. Utilizar os seguintes comandos:
set interface trust ip <ip privado rede local>/<mascara>

set interface trust nat
set interface untrust ip <ip público>/<mascara>
set interface tunnel.1 zone untrust

set interface tunnel.1 ip <ip da WAN>/30
3. Configuração das redes para as quais a política de IPSec será aplicada. Utilizar os seguintes
comandos:
set address trust rede_local <rede IP da LAN>/<Máscara>

set address untrust rede_remota <rede IP das redes remotas>/<mascara>
4. Configuração da Fase 1 do IKE.
Nessa fase será utilizado uma chave tipo PSK (Pre-shared Key), endereço IP público do ERX. O seguinte
comando será utilizado:
set ike gateway to_erx address <IP do ERX> main outgoing-interface untrust preshare <string da chave PSK>
proposal pre -g2-3des-sha
5. Configuração da Fase 2
Nessa etapa, serão necessários os parâmetros de identificação de rede local e remota. Deve ser utilizado o
endereço IP da rede LAN e da rede LAN IP do site ele será acessado pelo Netscreen via túnel IPSec.
set vpn "ns_erx" gateway "to_erx" no-replay tunnel idletime 0 proposal "g2-esp-3des-sha"
set vpn "ns_erx" id 1 bind interface tunnel.1
set vpn "ns_erx" proxy-id local-ip <endereco IP da LAN do NS>/<mascara> remote-ip <rede IP da LAN do
site destino "ANY"

6. Roteamento
Nessa etapa são configurados a parte de roteamento. Os comandos necessários são:
set vrouter trust-vr route 0.0.0.0/0 interface untrust gateway <endereco IP do gateway da rede, possivelmente
o IP da LAN do router/modem>
set vrouter trust-vr route <endereco IP da rede IP remota que se deseja acessar>/<mascara> interface tunnel.1
7. Policy de IPSec
Deverá ser criada policy IPSec para a VPN criada definindo os interesses de tráfego. Os seguintes comandos
são utilizados:
set policy top name to_net from trust to untrust rede_local rede_remota any permit
set policy top name from_net from untrust to trust rede_remota rede_local any permit
Procedimento de configuração do ERX
1. Criação do PSK (Pre-shared key)
Deve ser configurada a mesma chave utilizada no Netscreen. Utilizar o seguinte comando:
ipsec key manual pre-share <Endereco IP publico do cliente>

key <string que contem a PSK>
2. Criação do transform set para um dado cliente
ipsec transform-set <nome da transform set do cliente> esp-3des-hmac-sha
3. Criação do túnel IPSec.
O túnel Ipsec deve ser criado dentro da instância de roteamento (ou vrf):
CTAME_ERX_TESTE:default:vrf_vetor(config)# interface tunnel ipsec:<string que define o site do cliente>

transport-virtual-router default
tunnel source <endereco IP público do ERX>
tunnel pfs group 2
tunnel local-identity subnet <endereco da rede IP do site que será acessado via IPSEC na rede MPLS/VPN>
<mascara>
tunnel peer-identity subnet <endereco da rede IP cliente> <mascara>
tunnel transform-set <nome da transform set do cliente>
tunnel destination <endereco IP publico do cliente>
ip address <endereco IP da WAN do tunnel IPSec lado do ERX> <mascara>
4. Roteamento
Criar uma rota para a rede LAN do cliente, dentro da vrf do mesmo, através do comando:
ip route <rede IP do cliente> <mascara> <endereço IP da WAN do NS>

21. Anexo V: Solução VISANET
A solução CardConnect VISANET está baseada na topologia a seguir:
FRPR +RVW
9LVDQHW
) ORULDQySROLV
FRPR + RVW
$GP M $GPLQLVWUDGRUD M
' HD
I XOW
* :
&KHFNRXWV +RVW
7()
$&/ E
6H ,3 ' ( 6 7
6H [
,3 ' ( 6 7H, 3 25 ,* [ SHUPLWLU
9LVDQ ,3 ' ( 67
1$7 VHQmR
6H (VWiW QHJDU 1$7
6XE LQW
HUI E
,3 ' ( 6 7H, 3 25 ,* [ 6XE LQW
HUI D (VW
iW
$GPLQLVWUDGR M
['6/
N
5HGH,3 0 3/ 6
95)
1D 95) VmRFRQILJXUDGDVGXDV URWDV
$GP M HVWiWLFDVDP EDVFRP ,3 ' HVW
FRP QH[WKRS
UHVSHFWLYDPHQWHH
95) $V UHGHVH
9LVDQHW DSRQWDP SDUDRVGRLV FLUFXLW
RVYLUW
XDLV
GD9 LVDQHW
UHVSHFW
LYDP HQWH
)5
)5 0E
5HGH$ 7 0 ) 5 0E
G
['6/ / RD FH
%DO DQ ,3 ' ( 67
N
1$7
1$7 &LVFR +RVW
GH
(VWiW 3URGXomR
1$7
%U7 ) LO
LDO35
&KHFNRXWV 7()
9LVDQHW
' DWD&HQW
HU( ' 6 6 mR%HUQDUGR
Todos os estabelecimentos comerciais (lojas) devem ser conectados na VRF VISANET. A figura acima
indica os pontos na topologia onde devem ser configuradas as funcionalidade de NAT e ACL.
Deverão ser utilizados CPEs homologados pela GTAR para o serviço Vetor classe dados. Além da
configuração Vetor normal, deve ser configurado NAT conforme topologia acima.
Deve ser configurada no CPE uma rota estática para o endereço do host de transação da VISANET (endereço
/32) tendo como next hop o endereço da interface do PE Router.
Os servidores de transação da VISANET deverão ser mapeados para endereços IP públicos na faixa
200.200.0.0/16. A alocação destes endereços será realizada pela Brasil Telecom.

A figura a seguir ilustra a topologia utilizada durante o teste piloto com a VISANET. O endereço IP para as
interfaces WAN deve ser alocado conforme tabela na figura. Por exemplo, para acessos localizados no
Distrito Federal o endereço da interface WAN será do tipo 10.61.X.Y/30.
Teste com Visanet

200.200.200.1 Cliente "X"
como Host Visanet Loja 1 (Curitiba) 2005
Default GW = 192.168.0.254
Checkouts
TEF
192.168.0.0 / 24
.10 .1 .2
ACL
Se IP DEST 200.200.200.1
permitir
Se senão
IP DEST 200.200.200.1 (Visanet) e IP ORIG 192.168.0.x .254 negar
IP ORIG = 10.41.10.1
NAT
Estát .1
Cadeia de Lojas Cliente "X" xDSL

128 kbps
Rede: 10.41.10.0/24 (254 Lojas)
Rede IP / MPLS
Subredes:
Loja 1 : 10.41.10.1/32 10.41.10.1 / 32
Loja 2 : 10.41.10.2/32 VRF .61
Loja 3 : 10.41.10.3/32 Visanet
(V000163)
( ... ) 172.26.90.60 / 30
.65
172.26.90.64 / 30
FR (SPO 0421006)
2 Mbps
Rede ATM / FR Load
Balance
Faixa de Endereçamento das FR .62
Redes WAN 2 Mbps
.66 IP DEST 200.200.200.1 192.168.10.1
(SPO 0421007)
NAT
UF Faixa .25
Cisco 1721
PR 10.41.0.0 / 16 (SPO 0421014)
SC 10.48.0.0 / 16
RS 10.51.0.0 / 16
192.168.10.0/24
DF 10.61.0.0 / 16
GO 10.62.0.0 / 16
.1
TO 10.63.0.0 / 16
MT 10.65.0.0 / 16
MS 10.67.0.0 / 16 (Porta: 975)
AC 10.69.0.0 / 16
RO 10.69.0.0 / 16
Visanet
Host Data Center PROCEDA
21.1. Configuração de referência
As configurações a seguir foram utilizadas no teste piloto com a VISANET e deve ser adotada como
referência para o aprovis ionamento do serviço.
CONFIGURAÇÃO PE SPOPA301 (SITE CENTRAL)
interface ATM5/0/0.60 point-to-point

description CLIENTE_VISANET_2048K*SPO 0421006*2005/09/13
bandwidth 2048
ip vrf forwarding visanet
ip address 172.26.90.61 255.255.255.252
no ip directed-broadcast
no atm enable -ilmi-trap
pvc 1/160
oam-pvc manage 60

encapsulation aal5snap
interface ATM5/0/0.61 point-to-point

description CLIENTE_VISANET_2048K*SPO 0421007*2005/09/13
bandwidth 2048
ip vrf forwarding visanet
ip address 172.26.90.65 255.255.255.252
no ip directed-broadcast
no atm enable -ilmi-trap
pvc 1/161
oam-pvc manage 60
ip route vrf visanet 192.168.10.0 255.255.255.0 ATM5/0/0.60 172.26.90.62

CONFIGURAÇÃO PE BSACE705 (SITE REMOTO)
interface atm 0/2.67103

atm atm1483 description cpe0429704
atm pvc 67103 67 103 aal5snap 0 0 0
ip address 10.67.0.1 255.255.255.252
interface atm 0/2.67104

atm atm1483 description CLIENTE_VISANET*CPE0429705*11/11/2005
atm pvc 67104 67 104 aal5snap 0 0 0
ip address 10.67.0.5 255.255.255.252
CONFIGURAÇÃO CPE SPOPA301 (SITE CENTRAL)
interface Serial0
bandwidth 2048
no ip address
encapsulation frame -relay IETF
no fair-queue
frame -relay traffic-shaping
frame -relay lmi-type cisco
!
interface Serial0.1 point-to-point
description PVC SPO 0421006#V00163
bandwidth 2048
ip address 172.26.90.62 255.255.255.252
ip nat outside
frame -relay class DADOS-VETOR
frame -relay interface-dlci 20 IETF
!
interface Serial1

bandwidth 2048
no ip address
encapsulation frame -relay IETF
no fair-queue
frame -relay traffic-shaping
frame -relay lmi-type cisco
!
interface Serial1.1 point-to-point
description PVC SPO 0421007#V00163
bandwidth 2048
ip address 172.26.90.66 255.255.255.252
ip nat outside
frame -relay class DADOS-VETOR
frame -relay interface-dlci 20 IETF
!
interface FastEthernet0
description LAN PROCEDA
ip address 192.168.10.25 255.255.255.0
ip nat inside
speed 100
full-duplex
ip nat inside source static 192.168.10.1 200.200.200.1
ip classless
ip route 0.0.0.0 0.0.0.0 Serial0.1
ip route 0.0.0.0 0.0.0.0 Serial1.1
ip route 200.200.200.1 255.255.255.255 FastEthernet0
no ip http server
CONFIGURAÇÃO CPE BSACE705 (SITE REMORO)
enable secret 5 $1$g4k9$XOt46ucvi6MrxcEp1TTOy/

enable password 7 011E150A582B0208
!
interface Ethernet0
ip address 7.1.2.77 255.255.255.0
ip nat inside
no ip mroute-cache
hold-queue 100 out
!
interface ATM0
ip address 10.67.0.2 255.255.255.252
ip nat outside
no ip mroute-cache
no atm ilmi-keepalive
pvc 0/35
oam-pvc manage 60
!
dsl operating-mode auto
hold-queue 224 in
!
ip nat inside source list 1 interface ATM0 overload
ip classless
ip route 0.0.0.0 0.0.0.0 10.67.0.1

no ip http server
!
access -list 1 permit 7.1.2.0 0.0.0.255
dialer-list 1 protocol ip permit
22. Anexo VI: Multicast
22.1. Requisitos de Hardware e Sistema Operacional dos

Roteadores
• ERX versão JunOS 7.0 ou superior e placa de túnel

• 7600 versão 12.2.18 SXF ou superior
Esse anexo contém os procedimentos de configuração do Multicast para o PE e CE. É

admitido que toda rede foi anteriormente preparada (tanto Ps como PEs). Maiores
detalhes, consultar o documento de Arquitetura do MPLS.
Habilitar Multicast PE
No Cisco:
ip multicast-routing vrf <nome da vrf>
No Juniper, dentro do virtual router da MVPN, configurar:
virtual-router default:<vrf>
ip multicast-routing
Habilitar PIM PE
Cisco ou ERX
Configurar o pim na interface lógica IP que conecta o cliente através do comando:

ip pim sparse-mode
Configurar o valor do MDT no PE
No Cisco, dentro da instância da vrf, configurar:
mdt default <endereço de Multicast alocado para aquela MVPN.
No Juniper, dentro do virtual router da MVPN, configurar:
virtual-router default:<vrf>
interface tunnel gre:MTI-<nome da vrf> transport-virtual-router default

tunnel source <endereco da loopback 0 do virtual router default>
tunnel destination <valor do MDT>
tunnel mdt
ip address <endereço IP da loopback do virtual router default> 255.255.255.255
ip pim sparse-mode
Configurar o RP da VPN no PE
Cisco
Configurar o RP dentro da VPN, através do comando:
ip pim vrf <nome da vrf> rp-address <endereço IP do RP>
Juniper
Dentro do virtual router default:<nome da vrf>

ip pim rp-address <ip do RP>
Configurar o multicast, PIM e RP da VPN no CE
Habilitar o multicast routing:
ip multicast-routing

Habilitar o pim nas interfaces de WAN e LAN através do comando:
ip pim sparse-mode
Configurar o RP estatícamente:
ip pim rp-address <endereço IP do site escolhido como principal>
23. Anexo VII: Solução CARD

A Solução CARD é composta por uma família de soluções de acessos dedicados e discados para
transporte de transações eletrônicas entre os estabelecimentos comerciais e empresas de validação
de cartão de crédito e débito e prestadoras de informações de crédito de pessoas físicas e/ou
jurídicas.
A solução CARD poderá ser comercializada em conjunto com parceiros integradores ou parceiros
fornecedores de equipamentos de rede, desta forma existirão algumas variações da solução, como
indicado neste anexo.
A Solução CARD também tem o objetivo de substituir a Rede de Pacotes da Brasil Telecom para os
serviços X.25 dedicado e X.28 discado voltados ao transporte de transações eletrônicas e de
validação de cartão de crédito e débito.
23.1. Topologia genérica

A Solução Card está baseada na topologia genérica abaixo. Nesta topologia estão representadas
todas as soluções que compõem a Solução CARD.

/ 73
&
(
6
,3
U
R
HW
9
33
3
Na figura acima estão representados provedores de conteúdo com acesso IP (Provedores de

Conteúdo C e D) e provedores de conteúdo com acessos X.25 (Provedores de Conteúdo A e B).
Existem cadeias de lojas onde o Servidor TEF está localizado no seu site central (matriz) – clientes
3 e 4 da figura - e aquelas cadeias de lojas em que o Servidor TEF estará localizado numa área de
colocation no Cyber Datacenter da Brasil Telecom em Curitiba (clientes 1 e 2 da figura).
Para os clientes cujo servidor TEF está localizado em sua matriz, a comunicação entre este servidor
e o host de transação da operadora de cartão com acesso X.25 será realizada através de uma
conexão XOT (X.25 over TCP) entre o roteador Cisco da matriz e os roteadores GW X25
localizados na estação FNS em Florianópolis. A funcionalidade XOT no roteador da ma triz do
lojista deve ser configurada com a opção Failover da seguinte forma:
xot <ip-address-GWX25_1> <ip-address-GWX25_2>

Com esta configuração, se o primeiro Gateway X25 (GWX25_1 no comando acima) falhar, o
roteador da matriz tenta estabelecer uma conexão XOT com o segundo Gateway X25 (GWX25_2).
Para os clientes cujo servidor TEF está localizado no Cyber Datacenter da Brasil Telecom, a
comunicação entre os checkouts das lojas e o servidor TEF será realizada em IP através da rede
Vetor, e a comunicação entre o servidor TEF e o host de transação da operadora de cartão será
realizada em X.25 através de um roteador Cyclades.

Para os CPEs conectados nas VPN dos provedores de conteúdo tipo C e D (provedores de conteúdo
com abordagem em IP) deverá ser configurado NAT, seguindo o modelo especificado no Anexo V
(Solução Visanet) deste documento. Deverá ser configurada nas interfaces de acesso dos roteadores
PE MPLS uma ACL (Access Control List) para permitir o acesso somente aos hosts de transação /
conteúdo, bloqueando qualquer outra tentativa de comunicação.
Para os CPEs conectados em VPNs de provedores de conteúdo X.25 (VRF verde escura na figura),
deverá ser configurado NAT da seguinte forma:
Provedor de Conteúdo A
Mainframe FEP
PACPAR
RENPAC
Estação FNS
Endereços privados
definidos pela
X.25
Brasil Telecom 64 kbps
GW X25
Acesso
Vetor FR Provedor de Conteúdo B
ACL na interface de
acesso:
Se IP destino= IP z, permit
VPN
Senão, deny Conteúdos
X.25
XoT
Rede ATM / FR
Endereço IP Z
(IP privado definido
S0.1(XoT) X.25 pela BrT)
NAT overload entre Serial
1 (nat inside) e Serial 0.1 S0.2 S1 Cyclades
(nat outside). Cisco1721 PR 1000
GW
(translate)
(...) Servidor
TEF
MATRIZ
As seguintes definições devem ser adotadas:
• A alocação dos endereços privados dos links ponto-a-ponto dentro da VPN Conteúdos X.25
deve seguir o especificado no Anexo V (Solução Visanet).
• Nos roteadores de acesso no Cyber Datacenter e na estação FNS os PVCs das diversas
VPNs devem ser mapeados nas VLANs correspondentes através de VRFs que isolem os
tráfegos das diferentes VPNs. Portanto, este roteador deve suportar a funcionalidade de
Multi-VRF Costumer Edge (VRF Lite).
• Cada servidor TEF no Cyber Datacenter deve ser conectado numa VLAN específica, com
endereçamento privado definido ou acordado com o cliente (cadeia de lojas).

• Os endereços X.25 devem ser definidos pela Brasil Telecom em conjunto com o integrador.
• Deverá ser configurada e aplicada nas interfaces de acesso de cada roteador PE MPLS uma
ACL com a seguinte regra:
o Se IP Destino = 200.200.0.0/16 (Faixa dos HOTS de transação ou conteúdo)
§ Então, PERMIT
o Senão, DENY.
23.2. Solução dedicada em IP

A solução dedicada totalmente em IP está baseada na seguinte topologia:
&
6(
,3
WRU
9H

A figura abaixo é uma referência para a alocação de endereços IP para a solução dedicada:
FRPR +RVW
9LVDQHW
) ORULDQySROLV
FRPR + RVW
$GP M $GPLQLVWUDGRUD M
' HD
I XOW
* :
&KHFNRXWV +RVW
7()
$&/ E
6H ,3 ' ( 6 7
6H [
,3 ' ( 6 7H, 3 25 ,* [ SHUPLWLU
9LVDQ ,3 ' ( 67
1$7 VHQmR
6H (VWiW QHJDU 1$7
6XE LQW
HUI E
,3 ' ( 6 7H, 3 25 ,* [ 6XE LQW
HUI D (VW
iW
$GPLQLVWUDGR M
['6/
N
5HGH,3 0 3/ 6
95)
1D 95) VmRFRQILJXUDGDVGXDV URWDV
$GP M HVWiWLFDVDP EDVFRP ,3 ' HVW
FRP QH[WKRS
UHVSHFWLYDPHQWHH
95) $V UHGHVH
9LVDQHW DSRQWDP SDUDRVGRLV FLUFXLW
RVYLUW
XDLV
GD9 LVDQHW
UHVSHFW
LYDP HQWH
)5
)5 0E
5HGH$ 7 0 ) 5 0E
G
['6/ / RD FH
%DO DQ ,3 ' ( 67
N
1$7
1$7 &LVFR +RVW
GH
(VWiW 3URGXomR
1$7
%U7 ) LO
LDO35
&KHFNRXWV 7()
9LVDQHW
' DWD&HQW
HU( ' 6 6 mR%HUQDUGR

23.3. Solução dedicada IP / X.25

A solução dedicada com acessos IP nos estabelecimentos comerciais e X.25 nas operadoras de
cartão está baseada na seguinte topologia:
Cada roteador GW X25 na estação FNS deve ter possuir as seguintes características
mínimas:
• Suporte às funcionalidades XOT (X25 over TCP), VRRP, X25 RBP ( Record Boundary
Preservation for Data Communications Networks) e CEF;
• Processador e Fonte de energia DC -48V redundantes;
• Arquitetura modular;
• Módulo de interface com 8 portas seriais (V35 / RS-232);
• Uma interface Fast Ethernet.
A figura a seguir destaca uma conexão entre um estabelecimento comercial e as bandeiras

(provedores de conteúdo).

23.4. Solução discada

Esta solução consiste no transporte de transações eletrônicas a partir de acessos discados que podem
utilizar os protocolos de enlace X.28, SLDC, PPP Assíncrono e as aplicações ISO8583, VISA II ou
ASCII.
As chamadas serão atendidas e processadas pelo RAS da Lyra localizado no Cyber Datacenter da
Brasil Telecom e terá a função de encaminhar os pacotes de dados de cada transação para o host de
transação da operadora de cartão através de uma conexão IP ou X.25.
A solução está baseada na topologia abaixo:

23.5. Exemplo de configuração XOT (X.25 over TCP)

As configurações abaixo se referem aos testes realizados pela filial SC, conforme diagrama a seguir,
e servem de referência para o aprovisionamento do serviç o:

Detalhamento dos testes
Foram executadas ligações entre um usuário da rede, que programamos com o endereço
48710012345, conforme segue:
1) Origem 48710012345 – Destino Transpac 48201332 Resultado OK
2) Origem 48710012345 – Destino Embratel 14802521 Resultado OK
3) Origem 48710012345 – Destino Embratel 11133651 (Visa) Resultado OK
4) Origem Transpac 48201332 - Destino 48710012345 Resultado OK
5) Origem IP (R2) para IP Destino 10.64.9.200 conectando com x25 48201332 Resultado OK
6) Origem IP (R2) para IP Destino 10.64.9.222 conectando com x25 14802521(EBT)
Resultado OK
Configuração dos roteadores:

Configuração Roteador R1:
R1#show running-config
Current configuration : 618 bytes
version 12.2
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
hostname R1
enable password cisco
memory-size iomem 15
ip subnet-zero
x25 routing
call rsvp-sync
interface FastEthernet0
no ip address
shutdown
speed auto
interface Serial0
no ip address
encapsulation x25
no ip mroute-cache
x25 address 48710012345
x25 win 5
x25 wout 5
x25 ips 256
x25 ops 256
x25 idle 1
clockrate 64000
interface Serial1
no ip address
shutdown
ip classless
no ip http server
line con 0
line aux 0
line vty 0 4
password cisco
login
end
R1#
R2#wr t
Building configuration...


version 12.3
service pad to-xot
service timestamps debug datetime msec
hostname R2
boot-start-marker
boot-end-marker
no aaa new-model
ip subnet-zero
ip cef
x25 routing
interface Loopback0
ip address 10.1.2.2 255.255.255.0
interface FastEthernet0/0
ip address 10.64.9.101 255.255.255.0
no ip route-cache cef
no ip route-cache
no ip mroute-cache
duplex auto
speed auto
interface Serial0/0
no ip address
shutdown
interface Serial0/1
no ip address
encapsulation x25 dce
no ip mroute-cache
x25 win 5
x25 wout 5
x25 ips 256
x25 ops 256
x25 idle 1
router rip
network 10.0.0.0
no ip http server
ip classless
x25 route ^1 xot 10.64.9.100 xot-keepalive-period 10 xot-keepalive-tries 3 xot-s
ource Loopback0
x25 route ^5 interface Serial0/1 xot-keepalive-period 10 xot-keepalive-tries 3
x25 route ^4 xot 10.64.9.100 xot-keepalive-period 10 xot-keepalive-tries 3 xot-s
ource Loopback0
line con 0
line aux 0
line vty 0 4
password cisco
login

end
R2#
R3#wr t
Building config

version 12.3
service timestamps debug datetime msec
hostname R3
boot-start-marker
boot-end-marker
no aaa new-model
ip subnet-zero
ip cef
x25 routing
interface Loopback0
ip address 10.1.3.1 255.255.255.0
interface Ethernet0/0
ip address 10.64.9.100 255.255.255.0
no ip route-cache cef
no ip route-cache
no ip mroute-cache
half-duplex
interface Serial0/0
no ip address
shutdown
interface Serial0/1
bandwidth 19200
no ip address
encapsulation x25
no ip route-cache
no ip mroute-cache
x25 htc 20
router rip
network 10.0.0.0
no ip http server
ip classless
x25 route ^487 xot 10.64.9.101 xot-keepalive-period 10 xot-keepalive-tries 3 xot
-source Loopback0
translate tcp 10.64.9.200 x25 48201332
translate x25 48710012346 tcp 10.64.9.101

translate tcp 10.64.9.222 x25 14802521

line con 0
line aux 0
line vty 0 4
password cisco
login
end
R3#
Debug das chamadas executadas (Call Request, Call Accept, numero chamador, numero
chamado, janela,.....)
Chamada do numero X.25 48710012345 para Embratel 14802521
R1#14802521
Trying 14802521...Open
Trying < 192.124.164.25 , 23 >

Session 2
Red Hat Linux release 7.3 (Valhalla)
Kernel 2.4.18-3 on an i686
login:
Login incorrect
login:
Debug conexão
04:52:55: Serial0: X.25 O R1 Call (19) 8 lci 1024

04:52:55: From (11): 48710012345 To (8): 14802521
04:52:55: Facilities: (0)
04:52:55: Call User Data (4): 0x01000000 (pad)
04:52:56: Serial0: X.25 I R1 Call Confirm (20) 8 lci 1024
04:52:56: From (11): 48710012345 To (8): 14802521
04:52:56: Packet sizes: 128 128
04:52:56: Throughputs: 1200 1200

05:02:17 : From (11): 48710012345 To (8): 11133651
05:02:18: From (11): 48710012345 To (8): 11133651


05:02:18: Packet sizes: 128 128
05:02:18: Throughputs: 1200 1200
Chamada do numero X.25 48710012345 para Embratel 11133651 (VISA)
R1#11133651
Debug conexão

05:02:17: From (11): 48710012345 To (8): 11133651
05:02:18: From (11): 48710012345 To (8): 11133651
05:02:18: Packet sizes: 128 128
05:02:18: Throughputs: 1200 1200
Chamada do numero X.25 48201332 para 48710012345
ITBI_MASC01>48710012345
User Access Verification
Password:
Password:
Debug conexão:
04:56:03: Serial0 : X.25 I R1 Call (27) 8 lci 1

04:56:03: From (8): 48201332 To (11): 48710012345
04:56:03: Packet sizes: 128 128
04:56:03: Window sizes: 7 7
04:56:03: Throughputs: 1200 1200
04:56:03: Serial0: X.25 O R1 Call Confirm (3) 8 lci 1
Show das chamadas(canais virtuais) ocupados:
Confirmação dos canais virtuais ocupados no roteador R1 (show X.25 vc)

SVC 1, State: D1, Interface: Serial0

Started 00:00:38, last input 00:00:00, output 00:00:00
Line: 6 vty 0 Location: Host: 48201332

48201332 connected to 48710012345 PAD <--> X25
Window size input: 7, output: 7

Packet size input: 128, output: 128
PS: 4 PR: 5 ACK: 5 Remote PR: 2 RCNT: 0 RNR: no
P/D state timeouts: 0 timer (secs): 0
data bytes 1237/89 packets 44/37 Resets 0/0 RNRs 0/0 REJs 0/0 INTs 0/0
Line: 0 con 0 Location: Host: 48201332

48710012345 connected to 48201332 PAD <--> X25

Line: 0 con 0 Location: Host: 14802521

48710012345 connected to 14802521 PAD <--> X25 ç ====Embratel

R1#

Arquitetura IP-VPN e QoS do Serviço Vetor Release II

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Arquitetura IP-VPN e QoS do Serviço Vetor Release II

Загружено:

Авторское право:

Доступные форматы

Descrição de Arquitetura

Serviço Vetor – Release II

31 / 01 / 2007 – VERSÃO 5.8

Diretoria Adjunta de Tecnologia e Arquitetura Versão 5.8 Página 2 de 56

18.3. Requisitos e restrições da Rede .....................................................................33

Diretoria Adjunta de Tecnologia e Arquitetura Versão 5.8 Página 3 de 56

1. Descrição da Arquitetura de Rede

Diretoria Adjunta de Tecnologia e Arquitetura Versão 5.8 Página 4 de 56

2. Características das VPNs

Devido a restrições envolvendo a implementação do processo de OSPF, tanto na plataforma Juniper

o Aplicações associadas a cada uma das quatro Classes de Serviço:

Diretoria Adjunta de Tecnologia e Arquitetura Versão 5.8 Página 5 de 56

2.2. DADOS A SEREM DEFINIDOS PELA BRASIL TELECOM:

Classe de Serviço Perda de Retardo

Diretoria Adjunta de Tecnologia e Arquitetura Versão 5.8 Página 6 de 56

2.3. ROTEAMENTO IP NA VPN:

Diretoria Adjunta de Tecnologia e Arquitetura Versão 5.8 Página 7 de 56

Anuncio de Rota IGP

Diretoria Adjunta de Tecnologia e Arquitetura Versão 5.8 Página 8 de 56

3. Acessos Dedicados (CPEs)

3.1. MODELOS DE CPE:

Diretoria Adjunta de Tecnologia e Arquitetura Versão 5.8 Página 9 de 56

Diretoria Adjunta de Tecnologia e Arquitetura Versão 5.8 Página 10 de 56

4. Agregador Multisserviços (Juniper ERX)

Diretoria Adjunta de Tecnologia e Arquitetura Versão 5.8 Página 11 de 56

Deverão ser definidos os seguintes Virtual Routers:

A figura acima ilustra o cenário previsto, incluindo o atendimento de clientes DialNet.

Diretoria Adjunta de Tecnologia e Arquitetura Versão 5.8 Página 12 de 56

5. Roteadores de Acesso (Cisco 7500 / 7600)

Diretoria Adjunta de Tecnologia e Arquitetura Versão 5.8 Página 13 de 56

6. Rede Frame Relay / ATM

Voz + Multimídia => CLP=0

Todas células não marcadas,

PVP => CLP=1

Diretoria Adjunta de Tecnologia e Arquitetura Versão 5.8 Página 14 de 56

Diretoria Adjunta de Tecnologia e Arquitetura Versão 5.8 Página 15 de 56

8. Acesso vetor para múltiplos de E1

Diretoria Adjunta de Tecnologia e Arquitetura Versão 5.8 Página 16 de 56

Diretoria Adjunta de Tecnologia e Arquitetura Versão 5.8 Página 17 de 56

10. Acesso Remoto

10.1. DialNet (RAS)

Diretoria Adjunta de Tecnologia e Arquitetura Versão 5.8 Página 18 de 56

Diretoria Adjunta de Tecnologia e Arquitetura Versão 5.8 Página 19 de 56

Maiores detalhes sobre o procedimento de configuração do IPSec, consultar o anexo III.

11. RADIUS / LDAP / SDX

Diretoria Adjunta de Tecnologia e Arquitetura Versão 5.8 Página 20 de 56

NAT no VIP Router

Diretoria Adjunta de Tecnologia e Arquitetura Versão 5.8 Página 21 de 56

13. Quality of Service (QoS)

CODEC Voz G.729 (8 kbps), 20ms de sampling

A partir da configuração default e de coleta de informações sobre o tráfego de cada acesso, a

Diretoria Adjunta de Tecnologia e Arquitetura Versão 5.8 Página 22 de 56

14. Extranets para acesso a serviços de valor adicionado

DSLAM Acesso Internet

Diretoria Adjunta de Tecnologia e Arquitetura Versão 5.8 Página 23 de 56

• Endereços privados fornecidos pelos clientes 3x /30

Diretoria Adjunta de Tecnologia e Arquitetura Versão 5.8 Página 24 de 56

15. Interconexão (VPN Inter-AS)

Diretoria Adjunta de Tecnologia e Arquitetura Versão 5.8 Página 25 de 56

16. Multicast para MPLS/VPN

Funcionalidade do Multicast, ponto de vista do cliente

Diretoria Adjunta de Tecnologia e Arquitetura Versão 5.8 Página 26 de 56

Funcionalidade do Multicast, ponto de vista do Backbone IP