Datacom – L2VPN entre Datacom e Huawei

HUAWEI – L2VPN entre Datacom e Huawei

Obs.: Certifique-se de que o MPLS e LDP estão rodando corretamente entre os dispositivos.

Huawei

1 – Habilitar L2VPN

# mpls l2vpn

2 – Habilitar LDP

# mpls ldp

3 – Declarar o Vizinho MPLS LDP 

# mpls ldp remote-peer  

# remote-ip 192.168.99.112

# quit

4 – Criar a vlan

# vlan 2996

# description vpls-core-pop-a

# mtu 8000

# quit

5 – Atrelar a Vlan à VPLS

# interface vlan 2996

# description acesso-cliente-2996

# mtu 8000

# mpls l2vc 192.168.99.112 2996 ;#(A sintaxe a ser utilizada é: mpls l2vc ip_neighbor pw_id)

# quit 

6 – Conferir se a VPLS esta no ar

# display  mpls l2vc brief

Datacom

1 – Declarar o Vizinho MPLS LDP

# mpls ldp neighbor 192.168.99.111

2 – Criar a L2VPN e atrelar à vlan

# mpls vpws

# vpn 2996

# xconnect vlan 2996 vc-type vlan

# neighbor 192.168.99.111 pwid 2996 mplstype non-te

# no shutdown

# exit

CRIAR VLAN DATACOM

Vamos assumir em nosso exemplo a vlan 100.

a) Entrar no modo de configuração;

$ configure

b) Acessar o diretório da vlan 100

# intervace vlan 100

c) Inserir a interface 1/1 como membro tagged;

(config-if-vlan-100)#set-member tagged ethernet 1

É possível inserir uma range de interfaces 

(config-if-vlan-100)#set-member tagged ethernet range 1/5 1/8

d) Inserir a interface 4 como membro untagged;

(config-if-vlan-100)#set-member untagged ethernet 4

e) Para interfaces untagged, deve-se informar que a vlan nativa é a vlan acima (em nosso caso a vlan 100);

(config-if-vlan-100)# interface ethernet 4

(config-if-eth4)# switchport native vlan 100

(config-if-eth4)#exit

! Não esqueça de Salvar as configurações

# copy running-config startup-config

MPLS L2VPN

VPN tradicional

As VPNs tradicionais são baseadas no modo de transferência assíncrona ( ATM) ou no Frame Relay (FR), onde diferentes VPNs podem compartilhar a estrutura de rede das operadoras. As VPNs tradicionais têm as seguintes desvantagens:

l    A dependência de meios especiais (tais como ATM ou FR): Os transportadores devem estabelecer redes ATM ou redes FR para VPNs ATM ou baseado-FR em todo o país. Isso é um desperdício de construção de rede.

l    Estrutura VPN complicada: quando um site é adicionado a uma VPN existente, é necessário modificar a configuração de todos os nós de borda que acessam o site VPN.

O MPLS L2VPN evoluiu para superar as desvantagens mencionadas acima.

MPLS L2VPN

O MPLS L2VPN fornece serviços VPN de camada 2 na rede MPLS. Permite o estabelecimento de L2VPNs em diferentes mídias, incluindo ATM, FR, VLAN, Ethernet e PPP. Ao mesmo tempo, a rede MPLS fornece serviços IP tradicionais, MPLS L3VPN, engenharia de tráfego e QoS.

O MPLS L2VPN transfere dados da camada 2 do usuário de forma transparente na rede MPLS. A rede MPLS é uma rede de comutação da camada 2 usada para estabelecer conexões da camada 2 entre os nós.

Considere o ATM como um exemplo. Configure um circuito virtual ATM para cada dispositivo de borda do cliente (CE) para se comunicar com outro dispositivo CE através da rede MPLS, semelhante ao da rede ATM.

No MPLS L2VPN, os conceitos e os princípios de CE, PE e P são semelhantes aos do BGP / MPLS L3VPN.

Figura 6-1 Diagrama de rede do acesso da CE que adota ATM



Comparação com VPN BGP / MPLS

Comparado com a VPN BGP / MPLS, o MPLS L2VPN tem as seguintes vantagens:

l    Alta escalabilidade: O MPLS L2VPN estabelece relacionamentos de link da camada 2. Ele não importa e gerencia as informações de roteamento do usuário. Reduz significativamente a carga do dispositivo PE e da rede SP. Isso permite que a operadora suporte mais VPNs e mais usuários.

l    Confiabilidade e segurança garantida das informações de roteamento privadas: O MPLS L2VPN não pode obter e processar informações de roteamento de VPN porque não são importadas.

l    Suporte para protocolos da camada de rede, como IP, IPX e SNA.

Conceitos básicos de MPLS L2VPN

A Figura 6-2 mostra o modelo do MPLS L2VPN.

Figura 6-2 Modelo MPLS L2VPN

O MPLS L2VPN também usa a pilha de etiquetas para transmitir pacotes de usuários na rede MPLS de forma transparente.

l    circuito do acessório (CA): AC é um link ou circuito independente que conecta CE e PE. A interface CA pode ser uma interface física ou lógica. Os atributos AC incluem o tipo de encapsulamento, MTU e parâmetros de interface do tipo de link especificado.

l   Virtual Circuit (VC) : Refere-se a um tipo de conexão lógica entre dois PEs.

l    Túnel (túnel de rede): Transmite os dados do usuário de forma transparente.

Através da pilha de etiquetas, o MPLS L2VPN pode realizar a transmissão transparente do datagrama do usuário em uma rede MPLS.

l    Outer etiqueta: A etiqueta, que também é chamado túnel rótulo, é utilizado na transferência de pacotes a partir de um PE para outro.

l    Etiqueta interna: a etiqueta, também chamada de etiqueta VC no MPLS L2VPN, é usada para identificar diferentes links entre VPNs.. O PE no lado do receptor transfere pacotes para o CE correspondente de acordo com a etiqueta VC.

A Figura 6-3 mostra a alteração da etiqueta do pacote no processo de encaminhamento.

Figura 6-3 Processo de etiqueta MPLS L2VPN ing

A Figura 6-3 mostra a PDU (Layer 2 Protocol Data Unit) que é o pacote da camada de link.

Aqui, T representa o rótulo do túnel; V representa etiqueta VC; T ‘indica que a etiqueta externa é substituída no processo de encaminhamento.

Implementação do MPLS L2VPN

O grupo de trabalho Rede Privada Virtual Provisionada por Provedor (PPVPN) da IETF elaborou vários protocolos de estrutura. Dois dos protocolos mais importantes são o rascunho de Martini e o rascunho de Kompella.

l    draft-martini-l2circuit-trans-mpls: usa o LDP como o protocolo de sinalização para transferir informações da camada 2 e etiquetas de VC.

l    draft-kompella-ppvpn-l2vpn: usa o BGP como o protocolo de sinalização para transferir informações da camada 2 e etiquetas de VC.

O MPLS L2VPN também pode ser implementado através da configuração estática de rótulos de VC (como o CCC), sem o uso de protocolos de sinalização.

As seções a seguir descrevem a implementação do MPLS L2VPN.

6.1.2 CCC MPLS L2VPN

O Circuit Cross Connect (CCC) realiza o MPLS L2VPN por configuração estática.

Ao contrário do MPLS L2VPN comum, o CCC adota um rótulo para transferir dados do usuário, portanto, usa exclusivamente o LSP. Esses LSPs podem ser usados ​​apenas para transferir os dados desse link CCC e não podem ser usados ​​em outros links MPLS L2VPN, VPN BGP / MPLS ou usados ​​para transferir pacotes IP comuns.

Os dois tipos de conexão CCC são os seguintes:

l    Conexão local: refere-se à conexão entre dois CEs locais. Os dois CEs estão conectados ao mesmo PE. Semelhante a um switch de camada 2, o PE pode transportar pacotes diretamente sem configurar o LSP estático.

l    Conexão remota: refere-se à conexão entre o CE local e o CE remoto. Os dois ECs estão em PEs diferentes. Nesse caso, a configuração estática do LSP é necessária para transferir pacotes de um PE para outro PE. O comando de configuração é executado no PE para mapear o LSP estático para a conexão CCC.

6.1.3 SVC MPLS L2VPN

O SVC implementa o MPLS L2VPN através da configuração estática. O SVC transfere informações L2VPN sem usar os protocolos de sinalização. O rótulo do VC precisa ser configurado manualmente.

Ao criar a conexão estática L2VC do SVC, especifique o tipo de encapsulamento (LDP LSP, CR LDP).

O SVC não suporta conexão local.

Os rótulos usados ​​pelo CCC e pelo SVC variam de 16 a 1023. Eles estão no mesmo espaço de rótulos daqueles reservados para LSPs estáticos.

6.1.4 Martini MPLS L2VPN

O modo Martini implementa o MPLS L2VPN, configurando um link ponto a ponto. É necessário o LDP como protocolo de sinalização para transferir informações da camada 2 e etiquetas de VC.

O Martini MPLS L2VPN adota o tipo VC mais o VC-ID para identificar um VC entre dois CEs.

l    Tipo VC: indica o tipo do VC, como ATM (atm-aal5-sdu, atm-trans-cell), PPP, Ethernet, FR e HDLC.

l    VC-ID: O VC-ID de cada VC no mesmo tipo de VC deve ser exclusivo em todo o PE.

Os PEs que conectam dois CEs trocam etiquetas de VC por LDP e vinculam o CE correspondente por VC-ID.

Um VC é configurado quando todas as seguintes condições são atendidas:

l    O túnel entre os dois PEs foi criado com sucesso.

l    A troca de etiquetas e a ligação com a CE são concluídas.

l    O estado das duas interfaces do AC está ativo.

Para trocar rótulos de VC entre PEs, o Martini estende o LDP adicionando o tipo FEC no VC FEC. Para conexão remota, os dois PEs que trocam a etiqueta VC não podem ser conectados diretamente; portanto, a sessão LDP remota deve ser configurada para transmitir o VC FEC e a etiqueta VC.

Martini suporta inter-AS L2VPN no modo multi-hop. Mas ele não suporta conexão local.

O Graceful Restart (GR) é um recurso do Martini MPLS L2VPN. Após a troca do roteador, as etiquetas VC permanecem inalteradas. Durante a transição e após a transição, o VC permanece ativo.

Após a troca, se um rótulo diferente for recebido do par através do LDP, o rótulo antigo será excluído e o VC usando esse rótulo ficará inoperante.

6.1.5 Kompella MPLS L2VPN

Introdução

O modo Kompella usa o BGP como protocolo de sinalização para transferir informações da camada 2 e etiquetas de VC. Ele realiza o MPLS L2VPN por meio de ponta a ponta (CE para CE) na rede MPLS.

O Kompella MPLS L2VPN é diferente do Martini. Ou seja, ele não opera diretamente na conexão entre os CEs. Ele aloca VPNs diferentes em toda a rede SP e codifica cada CE na VPN. Semelhante à VPN BGP / MPLS, o Kompella MPLS L2VPN usa destinos de VPN para identificar diferentes VPNs que tornam a rede VPN mais flexível.

Para conectar dois CEs, é necessário configurar o ID do CE local e o ID do CE remoto no PE.

O Kompella suporta conexões locais e remotas. Ele suporta inter-AS L2VPN nos dois modos a seguir:

l    Modo multi-hop: adota rotas com etiqueta BGP.

l    Modo VRF para VRF: os ASBRs se consideram CEs.

Bloco de etiquetas

O Kompella MPLS L2VPN adota o bloco de etiquetas para alocar as etiquetas. Através dos blocos de etiquetas, as etiquetas podem ser alocadas para conexões ao mesmo tempo.

Os usuários especificam o intervalo de CE local que indica o número de CEs que podem ser conectados com este CE. O PE atribui um bloco de etiquetas para este CE. O tamanho do bloco de etiquetas é igual à faixa CE. Dessa maneira, os usuários podem reservar alguns rótulos extras para a VPN para uso futuro. A curto prazo, é um desperdício de recursos de etiqueta, mas reduz a carga de trabalho da implantação e configuração da VPN em expansão.

Suponha que uma VPN corporativa possua 10 CEs e o número possa aumentar para 20 devido à expansão do serviço no futuro. A faixa de CE de cada CE pode ser definida como 20 para atender a expansão futura. Se a VPN adicionar nós no futuro, será necessário modificar a configuração do PE diretamente conectado ao novo CE, sem modificar outros PEs.

Identificando origem de tráfego elevado em roteadores CISCO

Configurando o TOP Talkers no CISCO

Habilitando IP Flow na interface (ingress ou egress)

Verificando Tráfego

Boas Praticas para Melhorar a Seguranca de seu Provedor

Introdução

Aplicar boas práticas de segurança em Provedores de Internet faz parte do trabalho diário de operadores de redes e sistemas autônomos em geral como forma de assegurar, não apenas a boa operação da redes pelos quais é responsável e dos serviços prestados à seus clientes, mas também de modo a evitar que sua rede seja utilizada como fonte de problemas para redes de terceiros. Sendo a Internet uma interconexão de milhares de redes, se faz necessário a colaboração de todos os operadores de redes e sistemas autônomos em um esforço conjunto para se evitar que ocorram ataques, indisponibilidades, spam e consequentemente a perda da qualidade de navegação do usuário final e aumento de custos para todos.

Desde o surgimento da Internet a colaboração mútua de profissionais de diversas áreas tem sido essencial para se criar boas práticas para operação de redes e sistemas autônomos, sendo altamente recomendado segui-las e implementá-las, principalmente em ambientes que prestam serviço de acesso para milhares de usuários finais.

Para implementação de muitas dessas práticas nem sempre é necessário realizar grandes investimentos em equipamentos, mas apenas instruir a equipe responsável para que observem e sigam os guias de boas práticas existentes como também respondam à eventuais incidentes de segurança envolvendo a rede ou sistema autônomo pelo qual é responsável.

Nesse sentido o Núcleo de Informação e Coordenação do Ponto BR (NIC.br) há anos tem realizado um trabalho importante com iniciativas como a gerência da porta 25 e mais recentemente o Programa por uma Internet mais Segura e o MARNS para ajudar a melhorar a segurança dos sistemas autônomos Brasileiros.

Boas Práticas Gerais

Abaixo encontra-se uma lista não exaustiva de boas práticas a serem observadas por todos aqueles interessados em certifica-se de diversos aspectos de segurança na operação de um sistema autônomo. Como a lista pode receber novas recomendações é recomendado consultá-la de tempos em tempos para se certificar de que esteja operando sempre com as melhores práticas de segurança.

  1. Implementar as quatro ações do MARNS – https://bcp.nic.br/manrs
    1. Filtros de rotas de entrada e saída: evita o sequestro de prefixos (hijacking) e vazamento de rotas (leak). Verifique na ferramenta BGPStream (https://bgpstream.com/) se seu AS tem participado de sequestro de prefixos, vazamento de rotas ou ainda se houve outage envolvendo seu AS. A ferramenta dá uma visão dos últimos 180 dias.
    2. Implementar filtros de entrada antispoofing: evita que seus clientes gerem tráfego com endereço de origem alterado (spoofado) e iniciem ataques DoS tráfego spoofado e amplificado por destinos vulneráveis. Utilize a ferramenta CAIDA para verificar se em seu AS há medições de possibilidade de envio de tráfego spoofado e instale o software cliente do CAIDA (https://www.caida.org/projects/spoofer/) em segmentos de sua rede para verificar se ela permite tráfego spoofado.
    3. Atualizar os pontos de contato como mínimo no WHOIS e PeeringDB e também no RADb, como desejável.
    4. Publicar suas políticas de roteamento/ no RADb (desejável).
  2. Atender às notificações do CERT.br para serviços mal configurados que deixam portas abertas que podem ser abusadas. O CERT.br analisa 12 protocolos mensalmente (SNMP, DNS, NTP, SSDP, PORTMAP, NETBIOS, MDNS, MEMCACHED, CHARGEN, QOTD, LDAP e Service Discovery da Ubiquiti) e encaminha notificações com os IP ofensores, por AS, para o email que consta como Abuse no Whois.
  3. Implementar ações de hardening mapeando ameaças, mitigando riscos e tomando ações corretivas. Há várias dicas sobre autenticação, autorização, acesso, sistema e configurações na apresentação https://www.cert.br/docs/palestras/certbr-formacao-professores2019-turma01.pdf. Tópicos adicionais de hardening são apresentados nos cursos BCOP do NIC.br – https://cursoseventos.nic.br/curso/curso-bcop/
  4. Implementar gerência de porta 25 – http://www.antispam.br/admin/porta25/

Boas Práticas Especificas

Além das boas práticas gerais apresentadas acima é também altamente recomendado acompanhar a divulgação de patches de segurança, lançamento de novas versões de firmware/software e publicação de release notes de fabricantes de equipamentos de rede e softwares, utilizados na operação do provedor, para ficar sabendo quando alguma vulnerabilidade foi encontrada e corrigida e reduzir o tempo de exposição da sua rede para a Internet.

Cada fabricante mantém diferentes sistemas e métodos para dar publicidade à esses anúncios. As URLs abaixo são uma referência para algumas dessas ferramentas utilizadas pelos diferentes fabricantes e conteúdo relacionado.

Cisco

https://tools.cisco.com/security/center/softwarechecker.x
https://tools.cisco.com/security/center/publicationListing.x

Juniper

https://kb.juniper.net/InfoCenter/index?page=content&channel=SECURITY_ADVISORIES

Huawei

https://www.huawei.com/en/psirt/all-bulletins

Mikrotik

https://blog.mikrotik.com/security/
https://wiki.mikrotik.com/wiki/Manual:Securing_Your_Router

FONTE: https://wiki.brasilpeeringforum.org/w/Boas_Praticas_para_Melhorar_a_Seguranca_de_seu_Provedor

Gustavo Franco Pabx – Linux – Cisco – Juniper – Asterisk – VoIP – Redes – Telefonia