Arquitetura de linha de base de Routed Bridged Encapsulation

Introduction

Este documento descreve uma arquitetura de linha de assinante digital assimétrico (ADSL) ponta a ponta que utiliza o recurso RBE (Routed Bridged Encapsulation) do concentrador de acesso universal (UAC) Cisco 6400. O RBE foi criado para tratar das questões de RFC1483 Bridging conhecidas, incluindo tempestades de transmissão e segurança. Exceto pelo fato de operar exclusivamente sobre ATM, o recurso RBE funciona de forma idêntica ao half-bridging. Escalabilidade, desempenho e segurança adicionais podem ser obtidos utilizando-se as características exclusivas de assinantes xDSL.

Hipótese

A arquitetura da linha de base foi projetada usando o Modelo de arquitetura de referência de fórum ADSL. A arquitetura cobre diferentes ofertas de serviço do Network Access Provider (NAP) e cenários diferentes de como o tráfego do assinante é encaminhado para o Network Service Provider (NSP). Nesta arquitetura, o RBE é o método de encapsulamento presumido usado pelo Cisco 6400. O conteúdo deste documento é baseado em implantações existentes, bem como em alguns testes internos realizados na arquitetura. Para obter recursos e modificações aprimorados, consulte as notas de versão da versão mais recente do software Cisco IOS®. Atualmente, o RBE é suportado nas plataformas Cisco 6400, Cisco 7200 e Cisco 7500. Este documento se limita às discussões do Cisco 6400.

Resumo técnico

Do ponto de vista da rede, a conexão ATM se assemelha a uma conexão roteada. O tráfego de dados é recebido como pacotes RFC1483, mas eles são quadros RFC1483 Ethernet ou IEEE 802.3. Em vez de ligar o quadro Ethernet ou IEEE 802.3, como no caso de RFC1483 Bridging regular, o roteador roteia no cabeçalho da Camada 3. Com exceção de algumas verificações rápidas, o cabçalho de ligação é ignorado. Isso é explicado em detalhes na próxima seção.

Descrição operacional

Do ponto de vista operacional, o roteador opera como se a interface de ponte roteada estivesse conectada a uma LAN de Ethernet. A operação é descrita abaixo de duas maneiras: pacotes provenientes das instalações do cliente e pacotes destinados às instalações do cliente.

Para os pacotes originados no local do cliente, o cabeçalho Ethernet é ignorado e o endereço IP de destino é examinado. Se o endereço IP de destino está no cache de rota, o pacote é comutado rapidamente para a interface de saída. Se o endereço IP de destino não estiver no cache da rota, o pacote será enfileirado para switching do processo. No modo de switch de processos, a interface de saída por meio da qual o pacote deve ser roteado é localizado por meio de um exame da tabela de roteamento. Depois que a interface de saída é identificada, o pacote é roteado por meio daquela interface. Isso ocorre sem o requisito para o grupo de ponte ou a interface BVI.

Para pacotes destinados às premissas do cliente, o endereço IP de destino do pacote é examinado primeiro. A interface de destino é determinada no IP Routing Table. Em seguida, o roteador verifica a tabela Address Resolution Protocol (ARP) associada àquela interface para encontrar um endereço MAC de destino para colocar no cabeçalho de Ethernet. Se nenhum for localizado, o roteador gera uma requisição ARP para o endereço IP de destino. A solicitação ARP é encaminhada somente para a interface de destino. Isso contrasta com o bridging, no qual a solicitação ARP é enviada para todas as interfaces no grupo de bridge.

Em situações com interfaces não numeradas (em que você pode localizar dois assinantes na mesma sub-rede), a interface de ponte roteada usa ARP de proxy. Por exemplo, 192.168.1.2 (host A) desejar comunicar-se com 192.168.1.3 (host B). Entretanto, o host A está na mesma sub-rede que o host B.

O host A deve aprender o endereço MAC do host B enviando um broadcast ARP ao host B. Quando a interface de ponte roteada no dispositivo de agregação receber esse broadcast, ele enviará uma resposta ARP de proxy com o endereço MAC 192.168.1.1, Host A. Ele pegará esse endereço MAC, o colocará em seu cabeçalho Ethernet e enviará o pacote. Quando o roteador recebe o pacote, ele descarta o cabeçalho, examina o endereço IP de destino e, em seguida, roteia-o para a interface correta.

Vantagens de RBE

O RBE foi desenvolvido com a intenção de abordar algumas das questões enfrentadas ela arquitetura de RFC1483 Bridging. O RBE mantém as principais vantagens da arquitetura de RFC1483 Bridging, enquanto elimina a maioria de suas desvantagens.

• Configuração mínima no CPE (customer premises equipment).

  O provedor de serviço considera isso importante, pois não exige mais um grande número de visitas de técnicos e não precisa mais investir pesadamente em funcionários para o suporte de protocolos de nível superior. O CPE no modo de ligação age como um dispositivo muito simples. A solução de problemas mínima está envolvida no CPE, já que tudo o que vem da Ethernet passa diretamente para o lado da WAN.

• Fácil de migrar de arquiteturas de bridging puro para RBE. Não há alterações necessárias na extremidade do assinante.

• Evita os desafios de sequestro de IP e falsificação de ARP enfrentados em arquiteturas de bridging puras típicas. O RBE também impede tempestades de transmissão usando as conexões ponto a ponto. A segurança é a maior desvantagem das arquiteturas de bridging puro.

• Comparado a arquiteturas de Pure Bridging, o RBE fornece desempenho superior devido à implementação de roteamento no dispositivo de agregação. Além disso, o RBE é mais escalável porque não possui limitações de grupo de ligação.

• Oferece suporte à seleção da Web de Camada 3 usando o Cisco Service Selection Gateway (SSG).

Considerações de implementação

Alguns dos pontos principais a serem considerados antes da implementação desta arquitetura são os mesmos mencionados no documento RFC1483 Bridging Baseline Architecture.

O RBE é recomendado quando:

• Os cenários são idênticos aos das arquiteturas de Bridging existentes.

• O NAP quer somente realizar um gerenciamento mínimo de CPEs. O conceito de um CPE simples requer configuração mínima ou nenhuma depois que o CPE é implantado no local do assinante.

• Não é possível instalar o NAP e ele mantém os clientes de host nos hosts atrás do CPE transposto. Essas tarefas de instalação e manutenção aumentam os custos da distribuição e da manutenção, incluindo o fornecimento de uma equipe de helpdesk com conhecimento do software do cliente e do sistema operacional no qual ele está em execução.

• O NAP quer implantar uma rede de ponte escalável e segura usando CPEs existentes (que só podem operar no modo de ponte RFC1483) e deseja oferecer recursos de seleção de serviço.

A próxima discussão explica como a arquitetura do RBE se ajusta e se adapta a diferentes modelos de negócios.

Arquitetura de rede

A arquitetura da rede RBE é semelhante à arquitetura de RFC1483 Bridging. Conforme especificado nessa arquitetura, o dispositivo de agregação poderia estar no NAP ou no NSP. Quando uma arquitetura de PVC (Circuito virtual permanente) de ponta a ponta é utilizada, o NSP finaliza os assinantes e configura o RBE no dispositivo de agregação. Se o NAP prefere fornecer serviços por atacado e mais uma seleção de serviços, ele pode optar por concluir esses assinantes e obter endereços IP de um servidor DHCP de (Protocolo de configuração de host dinâmico) local. No caso dos serviços grossistas, o NAP pode optar por obter os endereços IP do NSP. Esses cenários são cobertos em detalhe na seção Gerenciamento de IP deste documento.

Considerações sobre o design da arquitetura RBE

O RBE elimina os principais riscos de segurança envolvidos na arquitetura de RFC1483 Bridging. Além disso, o RBE oferece um desempenho melhor e mais escalável, pois as subinterfaces estão sendo tratadas como interfaces roteadas.

Esta seção explica alguns dos pontos-chave que devem ser considerados antes de projetar a arquitetura RBE. No lado do assinante, os princípios de design permanecem os mesmos da arquitetura de RFC1483 Bridging.

No RBE, aloca-se uma rota, um conjunto de rotas ou uma sub-rede CIDR sem classe a um VC simples. Assim, o ambiente confiável é reduzido somente para as instalações do cliente único representadas pelos endereços IP no conjunto de rotas ou no bloco CIDR. O ISP também controla os endereços atribuídos ao usuário. Isso é feito através da configuração de uma subrede na subinterface desse usuário. Portanto, se um usuário configura mal o equipamento com um endereço IP fora do intervalo de endereços alocados (possivelmente fazendo com que os pacotes ARP fluam para o roteador), o roteador gera um erro de "cabo errado" e recusa-se a inserir o mapeamento de endereço IP para MAC errado em sua tabela ARP.

O RBE pode ser empregado usando apenas as subinterfaces ATM de ponto a ponto. Ele não pode ser implantado em subinterfaces multiponto. Mesmo se o assinante estiver em ponte, não será necessário definir os grupos de pontes nem as interfaces BVI pois as subinterfaces são tratadas como interfaces roteadas.

As subinterfaces ponto-a-ponto ATM podem ser interfaces numeradas ou não numeradas para algumas outras interfaces.

Por definição, uma interface numerada é uma interface que tem um endereço IP específico atribuído com uma máscara de sub-rede fixa. Por exemplo:

Interface atm0/0/0.132 point-to-point
ip address 192.168.1.1 255.255.255.252

Conforme demonstrado no exemplo, quando um RBE é implantado com uma interface numerada, deve existir uma sub-rede separada para cada assinante. O host na extremidade do assinante deve ser configurado para 192.168.1.2. Existe apenas um host na extremidade de assinante. Se o requisito é oferecer suporte a mais de um host, a máscara de sub-rede selecionada deve acomodar mais hosts.

As interfaces numeradas oferecem ao NAP controle sobre o número de hosts que o assinante tem conectado atrás do CPE. Como explicado acima, essa falta de controle foi o principal problema na arquitetura de RFC1483 Bridging.

Entretanto, esta metodologia consome endereços IP demais. Será necessário alocar uma sub-rede por assinante, usar um endereço IP para a sub-interface e deixar o endereço de difusão e todos os endereços zero sem uso. Por isso, para ter um host atrás do CPE, você precisa, no mínimo, definir uma máscara de sub-rede de 255.255.255.252. Considerando a escassez de endereços IP, essa pode não ser uma opção viável a menos que o NAP/NSP esteja usando espaço de endereço privado e executando a Network Address Translation (NAT) para acessar o mundo externo.

Para conservar endereços IP, uma alternativa seria usar interfaces não numeradas. Por definição, uma interface não numerada é uma interface que usa o endereço IP de outra interface usando o comando ip unnumbered. Por exemplo:

!
interface loopback 0
ip address 192.168.1.1 255.255.255.0
!
interface atm0/0/0.132 point-to-point
ip unnumbered loopback 0
!
interface atm0/0/0.133 point-to-point
ip unnumbered loopback 0

Conforme mostrado no exemplo acima, só se aplica uma sub-rede e endereço IP à interface de loopback. Todas as subinterfaces ATM estariam sem numeração para aquela interface de loopback. Neste cenário, todos os assinantes terminados em subinterfaces ATM (não numerados para loopback 0) estariam na mesma sub-rede do loopback 0. Isso implica que os assinantes estariam na mesma sub-rede, mas estariam entrando através de diferentes interfaces roteadas. Nessa situação, torna-se um problema para o roteador identificar qual assinante está por trás de qual subinterface ATM. Para o Cisco IOS, 192.168.1.0 (no diagrama de gerenciamento de IP) é conectado diretamente através do loopback de interface 0, e nunca enviará tráfego destinado a nenhum dos endereços de host naquela sub-rede através de qualquer outra interface. Para resolver esse problema, você precisa configurar explicitamente as rotas estáticas do host. Por exemplo:

ip route 192.168.1.2 255.255.255.255 atm0/0/0.132
ip route 192.168.1.3 255.255.255.255 atm0/0/0.133

Conforme especificado neste exemplo, quando o roteador precisa tomar uma decisão de roteamento e precisa encaminhar o tráfego destinado para 192.168.1.2, ele escolherá ATM 0/0/0.132 como a interface de saída e assim por diante. Sem especificar essas rotas de host estático, o roteador escolheria a interface de saída como loopback 0 e descartaria o pacote.

Ainda que a interface não numerada pudesse conservar endereços IP, ela exigiria uma tarefa adicional de configuração de rotas de host estático no processador de rotas de nó (NRP) para cada assinante. Observe que, se um assinante tiver, por exemplo, 14 hosts atrás do CPE, não é necessário ter rotas de host estático para cada host. É possível definir uma rota sumariada para a subinterface ATM.

Até aqui, esta explanação assumiu que os hosts por trás do CPE serão configurados para endereços IP estáticos. Essa suposição não é verdadeira em designs da vida real. No mundo prático, o NAP quer executar a configuração e manutenção mínimas para o CPE e os hosts anexados a ele. Para conseguir isso, os hosts devem obter seus endereços dinamicamente usando um servidor DHCP.

Para obter seus endereços IP dinamicamente, os hosts devem ser configurados para obter endereços IP de um servidor DHCP. Quando o host inicializa, ele envia solicitações DHCP. Estas solicitações são então retransmitidas para o servidor de DHCP apropriado, que atribui um endereço IP para o host a partir de um em seu escopo previamente definido.

Para encaminhar as solicitações DHCP iniciais do host para o servidor DHCP apropriado, você deve aplicar o comando ip helper-address à interface que está recebendo os broadcasts. Depois que os broadcasts são recebidos, o Cisco IOS examina a configuração do ip helper-address para essa interface e encaminha essas solicitações em um pacote unicast para o servidor DHCP apropriado cujo endereço IP é especificado no ip helper-address. Após o servidor DHCP responder com o endereço IP, ele envia a resposta para a interface no roteador que encaminhou originalmente a solicitação. Isso é usado como interface de saída para enviar a resposta do servidor de DHCP para o host que requisitou o serviço originalmente. O roteador também instala automaticamente uma rota do host para esse endereço.

Se o RBE estiver habilitado em uma subinterface e for uma unidade de dados de protocolo de ponte (PDU - Bridged Protocol Data Unit) IEEE 802.3, o encapsulamento Ethernet será examinado após o encapsulamento da ponte ATM. Se for um pacote IP/ARP, será tratado como qualquer outro pacote IP/ARP. O pacote IP faz Switch rápido. Se falhar, ele será enfileirado para switching de pacotes.

O desempenho do RBE é uma grande vitória. O código de Bridging padrão de hoje tem o problema inerente de exigir duas classificações separadas para um pacote antes que uma decisão de encaminhamento possa ser tomada. A classificação é definida como o processo de examinar (no upstream) e modificar (no downstream) o cabeçalho de pacote para informações de encaminhamento, que são relativamente dispendiosas. Uma consulta de Camada 2 é necessária para determinar se o pacote precisa ser roteado ou ligado em ponte. Em seguida, na Camada 3, uma consulta é necessária para identificar o local para o qual o pacote deve ser roteado. Essa classificação é feita nas direções upstream e downstream, o que tem um impacto no desempenho.

Para o RBE, a configuração predetermina que o pacote seja roteado no sentido upstream. Portanto, não é necessário passar pelo caminho de encaminhamento de bridging, que foi necessário no caso de bridging padrão.

Pontos principais do RBE

CPE

A configuração do CPE continua a mesma do Bridging padrão. Nenhuma alteração é necessária em CPE para distribuir RBE.

Gerenciamento de IP

Durante a implantação das interfaces numeradas para RBE, a alocação de endereço IP para o host por trás do CPE interligado é geralmente tratada por meio de um servidor DHCP. Como mencionado anteriormente, o servidor DHCP pode residir no NAP ou no NSP. Em ambos os casos, a subinterface ATM numerada deve ser configurada com o comando ip helper-address. Se o servidor DHCP for ser localizado no NSP, o dispositivo de agregação NAP deve ter uma rota para atingir esse servidor. O único cenário em que um NAP deve usar seu próprio servidor DHCP e intervalo de endereços IP é quando se pretende que o NAP ofereça capacidades de seleção de serviço aos assinantes, sendo que estes assinantes compõem uma LAN vinculada ao NAP.

Se o NAP quiser usar o espaço de endereço IP do NSP, um dos endereços IP de cada sub-rede deverá ser alocado à subinterface ATM. Além disso, deve haver algum acordo mútuo entre o NAP e o NSP para que o NAP configure o endereço correto. Quando o servidor DHCP do NSP atribui endereços IP, esse acordo deve vigorar para garantir que o servidor forneça as informações corretas de gateway padrão ao host. O NAP pode, então, resumir uma rota estática para todos os endereços atribuídos aos assinantes ou optar por executar um protocolo de roteamento com o NSP para anunciar essas rotas. Na maioria dos cenários, o NAP e o NSP prefeririam não usa um Routing Protocol. Fornecer uma rota estática é uma boa opção.

Esta é a configuração básica necessária no NRP para implantar o RBE com interfaces numeradas:

!
interface ATM0/0/0.132 point-to-point
ip address 192.168.1.1 255.255.255.0
ip helper-address 192.168.3.1
no ip directed-broadcast
atm route-bridged ip
pvc 1/32
encapsulation aal5snap
!
interface ATM0/0/0.133 point-to-point
ip address 192.168.2.1 255.255.255.0
ip helper-address 192.168.3.1
no ip directed-broadcast
atm route-bridged ip
pvc 1/33
encapsulation aal5snap

Usar interfaces não numeradas é a melhor maneira de conservar endereços IP. Como explicado anteriormente, quando interfaces não numeradas são usadas com DHCP, as rotas de host são instaladas dinamicamente. Essa pode ser a melhor abordagem para a distribuição de RBE. O servidor DHCP pode então ser localizado no NAP ou no NSP, como para interfaces numeradas.

Esta é a configuração básica necessária no NRP para implantar o RBE com interfaces não numeradas:

interface Loopback0
ip address 192.168.1.1 255.255.255.0
no ip directed-broadcast
!
interface ATM0/0/0.132 point-to-point
ip unnumbered Loopback0
no ip directed-broadcast
ATM route-bridged ip
pvc 1/32
encapsulation aal5snap
!
interface ATM0/0/0.133 point-to-point
ip unnumbered Loopback0
no ip directed-broadcast
ATM route-bridged ip
pvc 1/33
encapsulation aal5snap

Como um destino de serviço é alcançado

Até agora, este documento discutiu a tecnologia de acesso básica usando o RBE como o método de encapsulamento. No entanto, usando essa arquitetura, o NAP/NSP também pode oferecer vários serviços e diferentes opções para onde o NAP pode encaminhar o tráfego do assinante para o NSP. Esses conceitos são explicados nas próximas seções.

Fornecendo acesso à Internet

Nesse cenário, a principal função do NSP é permitir acesso de alta velocidade à Internet aos assinantes. Como o NSP vai fornecer o serviço final, o gerenciamento de endereços IP torna-se responsabilidade do NSP. Ele pode atribuir endereços de IP públicos para os seus assinantes finais usando um servidor DHCP ou pode optar por fornecer endereços de IP privativos aos assinantes e, em seguida, realizar a NAT para alcançar o mundo exterior.

Serviços por atacado

Se o NAP quiser oferecer serviços de atacado para outros ISPs, ele poderá fazê-lo. Nesse cenário, o NAP geralmente não prefere tratar endereços IP para todos os assinantes de NSPs diferentes. O NAP faz algum acordo com o ISP para fornecer endereços IP a esses assinantes. Isso pode ser feito pelo NAP encaminhando as solicitações DHCP vindas dos assinantes para os servidores DHCP nos NSPs. O NAP precisa configurar suas subinterfaces ATM com um dos endereços IP desse intervalo e deve anunciar essas rotas ao NSP. O anúncio de rotas pode estar na forma de uma rota estática ou de algum Routing Protocol entre o NAP e o NSP. A rota estática é o método preferível para o NAP, assim como o NSP.

Acesso corporativo

O acesso corporativo geralmente exige serviços de VPN (Rede Privada Virtual). Isto significa que a corporação não fornecerá nenhum endereço IP para o NAP e não permitirá que o NAP anuncie o espaço de endereço IP corporativo no núcleo de IP do NAP, pois isso poderia resultar em ruptura de segurança. As corporações geralmente preferem aplicar seus próprios endereços IP a seus clientes ou permitirão o acesso por meio de algum dispositivo protegido, como Multiprotocol Label Switching/Virtual Private Network (MPLS/VPN) ou Layer 2 Tunneling Protocol (L2TP).

A outra abordagem para fornecer acesso corporativo seguro é onde o NAP fornece os endereços IP iniciais a esses assinantes. Portanto, os assinantes se tornam conectados à LAN ao NAP. Depois que os assinantes tiverem endereços IP iniciais, eles podem iniciar um túnel para a corporação por meio do software de cliente L2TP que executa no host. Por sua vez, a corporação autenticará esse assinante e fornecerá um endereço IP de seu espaço de endereços IP. Esse endereço IP é usado pelo adaptador L2TP VPN. Dessa forma, os assinantes têm a opção de se conectar ao ISP para conexão com a Internet ou obter acesso à sua empresa por meio de um acesso seguro ao túnel L2TP. No entanto, isso exige que a corporação forneça o endereço IP de destino do túnel ao assinante, que deve ser roteável através do núcleo IP do NAP.

Capacidades de seleção de serviço

O NAP pode oferecer vários recursos de seleção de serviços usando a funcionalidade SSG da Cisco. O SSG oferece dois métodos para fornecer seleção de serviço: através da seleção da Web da camada 2 (conhecida como PTA-MD) e da camada 3. Com o RBE, pode ser usado apenas o método de seleção da web de camada 3. Isso exige que os assinantes sejam conectados à LAN ao NAP; ou seja, o NAP fornece o endereço IP inicial ao assinante e fornece acesso ao Cisco Service Selection Dashboard (SSD).

No caso da arquitetura RBE, o método de seleção da Web do Cisco SSG é uma boa maneira de considerar o tráfego de assinante.

Conclusão

O RBE oferece melhor desempenho e é mais escalável que o bridging padrão. Ele também supera todos os problemas de segurança enfrentados no Bridging padrão. O RBE elimina os problemas de tempestade de difusão do Briding padrão. O RBE fornece uma arquitetura robusta para o NAP que deseja evitar a manutenção do software do host cliente, problemas relacionados a bridging e deseja custos de implantação mais baixos. Com o RBE, tudo isso é possível enquanto a arquitetura de Bridging existente estiver sendo utilizada.

Informações Relacionadas

• Informações de suporte do produto ADSL da Cisco
• Suporte Técnico e Documentação - Cisco Systems