[GTER] RES: Restrições em circuitos layer 2

Mon Apr 26 09:40:14 -03 2010

Bom dia Herbert, demais,

Seria interessante verificar se algum dos "seus" endereços MAC relevantes estavam na tabela desse switch "apontando" para a interface certa quando ocorreu o problema, se ela estava realmente cheia ou não, e se outros serviços que passam pelo mesmo nó são afetados também. Concordo 100% com o Rubens que limpar a tabela MAC como solução não prova que houvesse exaustão de entradas MAC antes (pode simplesmente limpar um bug, como citado), e nem a exaustão momentânea em si (levando a flooding) causaria necessariamente a parada do serviço, cada switch/fabricante pode se comportar diferentemente. 

Assumindo que a Provedora Metro está tendo problemas com esgotamento da tabela MAC do Core QinQ dela, tunelar seu próprio tráfego via PBB e reduzir sua "contribuição" de MACs não significa que o problema seja eliminado, os 2 MACs do tunel PBB ainda têm que ser aprendidos. Já se a Operadora em si usasse PBB para implementar os serviços (em vez de QinQ), isso sim resolveria problemas de exaustão de tabela MAC no Core dela (se isso está ocorrendo), já que com PBB *nenhum* endereço MAC de cliente de nenhum serviço é aprendido no Core. Com relação a IPv4/IPv6, para o switch fazendo camada 2 (enxerga apenas MACs) não importa se o MAC veio de um host IPv6 ou IPv4. Apenas vale notar que uma diferença entre ARP e Neighbor Discovery é que o ND usa multicast, e não broadcast...em teoria é possível alguma condição de bug afetar seletivamente só broadcasts. 

Como sugestão para minimizar mal-entendidos com Provedoras Metro a respeito das expectativas de cada serviço L2VPN, etc. é sempre bom procurar usar a terminologia do Metro Ethernet Forum: E-LAN (serviço multiponto), E-LINE (serviço ponto-a-ponto), E-TREE (serviço ponto-multiponto) e seus atributos respectivos. Serviços EVPN podem ter acesso via porta inteira ou VLAN TAG (ex E-LINE pode ser EPL ou EVPL) . MEF 6.1 descreve tudo em detalhes:  <http://metroethernetforum.org/index.php> http://metroethernetforum.org/index.php

Serviços E-LINE não requerem aprendizado de endereços MAC de clientes (chamados C-MAC), mesmo quando implementados sobre Ethernet (PBB/PBT), já que o EVC tem apenas um caminho. Tecnologias usadas para implementar E-LINE seriam PWE3 (Ethernet pseudowires sobre MPLS), PBB E-LINE, PBT, e EPL sobre SDH/GFP. A Operadora não impõe limites de C-MACs pois não aprende esses endereços nem faz forwarding baseado neles. Já serviços E-LAN requerem aprendizado de C-MAC na porta UNI-N (na entrada da rede), qualquer que seja a tecnologia utilizada dentro da operadora (MPLS, SDH, Ethernet PBB/PBT, etc.), pois o switch de borda ("PE") precisa tomar a decisão de encaminhar frames a uma das possíveis UNI remotas. Tecnologias usadas para implementar E-LAN seriam VPLS/H-VPLS em MPLS, PBB E-LAN, ou RPR/SDH. Como existe C-MAC-learning na borda, a Operadora *pode* sim limitar a quantidade de C-MACs (e em geral o fazem) para cada serviço, forçando uma restrição de MACs para evitar que uma só E-LAN consuma todas as entradas FIB do switch, da mesma maneira que VRFs (RFC 2547) limitam a quantidade máxima de rotas aprendidas por cada L3VPN. Implementações diferentes adotam ações diferentes quando a tabela C-MAC enche, pode-se fazer flooding, descartar, etc. Em geral flooding indiscriminado faz mal à saúde da CPU/NPU do switch. No caso do VPLS da Cisco (não falo com nenhuma autoridade em Cisco, é só para citar exemplo) parece existir uma opção "shutdown".. (charming...)  <http://www.ciscosystems.com/en/US/docs/ios_xr_sw/iosxr_r3.7/mpls/configuration/guide/gc37vpls.html> http://www.ciscosystems.com/en/US/docs/ios_xr_sw/iosxr_r3.7/mpls/configuration/guide/gc37vpls.html

QinQ não faz E-LINE nativamente, pelo menos não sem ajustes na implementação (MAC learning, etc.) Pode-se fazer um E-LAN com 2 pontos só, mas isso não significa que ele seja um E-LINE nativo. Outra coisa é que "clear channel" não é um termo formalmente usado em Metro Ethernet, o que pode gerar confusão. O conceito e grau de "transparência" em EVPN depende do tipo de serviço (E-LINE, etc.), atributos, se o acesso é via VLAN-TAG ou porta, tratamento de protocolos de controle (LACP, 802.3X, xSTP, GARP, etc). Tipicamente, *pode-se* obter um serviço E-LINE completamente transparente a nível 2, implementado sobre MPLS ou SDH ou Ethernet PBB/PBT (tanto faz para o usuário). E-LAN exige alguma terminação/descarte (serviço é LAN, não é link, 100% transparente não faz sentido.. pra onde mandar um frame PAUSE ou LACP recebido?). Em todos esses serviços "Carrier Ethernet" implementados em cima de MPLS ou SDH ou Ethernet PBB/PBT, não há C-MAC learning no Core (como há no QinQ), pois o frame está tunelado e a decisão de forwarding não é baseada em MAC de cliente.

Conforme mencionado já existem vários fabricantes disponibilizando soluções PBB/802.1ah (Extreme, Ciena, Avaya, Brocade, Alcatel-Lucent, Cisco, Ericsson, Huawei, etc.), mas deve-se investigar em detalhe quais serviços (E-LINE, E-LAN, etc.) e funcionalidades são disponibilizados pela implementação, pois nem todos fazem tudo. A propósito Rubens, apenas uma pequena correção, o switch MERS 8600 (Metro-ERS) que desenvolvíamos na Nortel (pioneira do padrão PBB) seguiu oficialmente para a Ciena. O ERS 8600 (versão Enterprise com mesmo hw, mas sem PBB no momento) é que seguiu para Avaya, e segundo a Avaya parece que virá a ter PBB em breve. 

Leonardo.

-----Original Message-----

From: gter-bounces at eng.registro.br [ <mailto:gter-bounces at eng.registro.br> mailto:gter-bounces at eng.registro.br] On Behalf Of Herbert Faleiros

Sent: Friday, April 23, 2010 6:03 PM

To: Rubens Kuhl

Cc: Grupo de Trabalho de Engenharia e Operacao de Redes

Subject: Re: [GTER]RES: Restrições em circuitos layer 2

2010/4/23 Rubens Kuhl <rubensk at gmail.com>:

> Links L2 implementados em cima de SDH ou de MPLS não limitação de MACs

> pois não envolvem processo de MAC-learning na operadora.

infelizmente (p/ este caso específico) a rede em questão é Metro Ethernet, mas temos um circuito SDH com outra operadora instalado aqui no NOC, fica como opção caso não tenha solução pelo circuito atual.

--

Herbert

--

gter list  <https://eng.registro.br/mailman/listinfo/gter> https://eng.registro.br/mailman/listinfo/gter