MVPN-L3 sobre VPN-L2
Autor: Bruno Barata | Publicado: 2012-05-08T12:20:00-03:00





1
&nbsp;&nbsp;&nbsp;&nbsp; MPLS VPN – Virtual Private Network


1.1&nbsp;&nbsp;&nbsp; Conceitos
de VPN MPLS

•&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Customer
Edge router (CE) – É o dispositivo localizado físicamente no cliente. Ele
conecta a rede do provedor usando tecnologia nível 2 como Frame Relay, ATM, or
Ethernet. 

·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Nas VPNs layer 3, o CE forma
uma relação de protocolo para trocar conhecimentos de rota. O
router CE pode ser o único dispositivo em uma localidade de um determinando
cliente, ou pode participar de um domínio de roteamento de uma localidade. 

·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Para VPN Layer 2, o CE
transmite frames para o provedor que são destinados a um cliente remoto. O CE
pode ter uma única rota estática que aponta para o provedor, ou pode se
comunicar por protocolo de roteamento com outro CE.

•&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Provider Edge router (PE) – É o
dispositivo localizado no provedor e se comunica diretamente com o CE. Ele
mantém relacionamento com outros routers dentro do provedor.

·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Para L3VPN o PE se comunica com
o CE para receber atualizações de rotas. Essas informações são passadas para o
PE router conectado ao outro CE do cliente. Quando o PE router recebe pacotes
destinados ao site remoto ele encaminha o pacote usando MPLS LSP através do
provedor.

·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Para L2VPN ele simplesmente
recebe o frame L2 do CE local que encaminha para o PE remoto usando MPLS LSP.

•&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Provider
router – Localizado no core do provedor. O P não tem nenhum conhecimento da
VPN do cliente, simplesmente encaminha pacotes MPLS de um PE para o outro;

•&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
VPN
routing and forwarding table – Em
 L3VPN, todos os PEs mantem uma VPN routing and forwarding
table (VRF) separada para cada cliente conectado no PE. Cada tabela VRF contém conhecimentos
de roteamento específico para a rede do cliente. Quando o CE anuncia rotas de
uma localidade, o PE as coloca na tabela VRF. O router então anuncia para o PE
remoto que o anuncia para o CE remoto.


1.2&nbsp;&nbsp;&nbsp;
Layer 3
VPNs

Com Layer 3 VPN, o
cliente anuncia conhecimento de roteamento IP para a rede do provedor. O ISP
anuncia essas informações de roteamento através da rede para as outras
localidades do cliente. Esse conceito simples requer coordenação entre o
provedor e o cliente. A rede do provedor deve ser configurada para suportar
anúncios dessas rotas.

•&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
VPN
Network Layer Reachability Information (NLRI) – Um dos principios do core
para operação de VPN é manter a separação com a rede do cliente. As regras
normais do BGP fazem dessa uma tarefa dificil quando várias versões da mesma
rota passam através do algorítimo de seleção e somente um único caminho é
escolhido. Layer 3 VPN usa um formato especial para representar as rotas dos
clientes. Esse formato permite que cada router do provedor veja as rotas de
cada cliente de forma diferente mesmo quando eles anunciam o mesmo prefixo.
Para anunciar a NLRI requer o estabelecimento de sessões MBGP entre os PEs.

•&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Distinção
de Rotas – É um campo de 8-octet que consiste em 3 partes Type, the
Administrator, and Assigned Number fields.

•&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Type of RD indica qual o tamanho do campo do
Administrator e do Assigned Number, sendo 0 o Assigned Number maior e 1 o
Administrator maior.

•&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Quando o Administrator tem 2-octet é colocado o
AS, quando é de 4-octets é usado o router ID do PE que originou.

•&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Basic
Operational Concepts – Quando se usa L3VPN, você precisa estar por dentro
de tanto da operação dos anúncios de rota e do encaminhamento de pacotes.

·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
The Control Plane (anúncios de rotas) –
Rotas de clientes em uma L3VPN
são anunciadas entre os PEs da rede do provedor. Para
garantir que essas rotas serão entregues para o cliente final, o provedor tem
duas escolhas:

·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
The Data Forwarding Plane
(encaminhamento de pacotes) – Uma vez que rotas apropriadas são anunciadas e
recebidas pelo CE, o cliente pode começar a encaminhar dados atraves da red do
cliente.



•&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Usando
BGP para anúncio de rotas PE-CE - Permite o uso de RIP, OSPF, e BGP como
protocolo de roteamento para a conexão CE-PE connection. 

•&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Internet
Access for VPN Customers – O cliente mesmo tendo uma VPN ele pode solicitar
acesso a Internet. Existem 3 jeitos de fazer: Acesso de for a da tabela VRF,
Acesso distribuido para cada site VPN e acesso centralizado de um único site

·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Acesso independente – A tabela de
roteamento do PE nunca é consultada para encaminhamento de pacotes. O CE tem
que encaminhar trafego direto pra internet.

·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Acesso Distribuido – Configuração de 2
circuitos independetes na interface do CE. Um com VPN e outro sem.

·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Acesso Centralizado – Um CE possui
acesso compartilhado e todos os outros encaminham tráfego pra ele destinado a
internet.


2 &nbsp;&nbsp;&nbsp;&nbsp; Multicast VPN

A solução da Cisco de Multicast dentro de VPN
Multicast é simples e bastante escalável. A arquitetura MVPN introduz
protocolos e processos que ajuda a permitir que um ISP suporte multicast dentro
de VPNs. O transporte de multicast através do backbone do ISP é transparente e
é integrado de forma transparente a solução MPLS VPN. 

A solução MVPN é baseado no Draft IETF
draft-rosen-vpn-mcast-08.txt. A solução MVPN usa o GRE com uma arvore de encaminhamento
chamada multicast distribution tree (MDT) para realizar a escalabilidade do
multicast dentro do core network. O Cisco MVPN é Baseado em uma solução de
domínio Multicast com os recursos default MDT e data MDT. O MVPN introduz
informações de roteamento multicast na tabela de roteamento da VRF criando uma
Multicast VRF.

É importante notar que o uso de MVPN não
modifica o jeito que a rede do cliente é administrada em relação a Endereçamento,
politicas de roteamento, topologia, etc. Também é importante lembrar que as
redes multicast dos clientes não possuem nenhuma relação com a rede multicast
do provedor. Da visão do provedor, os pacotes multicast dos clientes são
meramente dados.


3 &nbsp;&nbsp;&nbsp;&nbsp; AToM

O Any Transport over MPLS (AToM) é uma solução
usada para transportar pacotes L2 através de um backbone MPLS. O AToM permite a
conectividade entre os sites dos clientes com suas tecnologias L2 existentes através
da infraestrutura de rede baseada em pacote.

Com a tecnologia AToM o aprovisionamento e a
conectividade são diretas. Um cliente usando Ethernet num edifício ou campus em
um local pode se conectar por meio de um provedor via Ethernet sobre MPLS a
clientes em locais remotos.



AToM estabelece um quadro comum para encapsular
e transportar trafegos Layer 2 sobre a rede MPLS. Os provedores podem usar uma
infra-estrutura única MPLS para oferecer aos clientes a conectividade Layer 2.

O AToM suporta os tipos de transporte abaixo:

•&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ATM AAL5 over MPLS

•&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ATM Cell Relay over MPLS

•&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Ethernet VLAN over MPLS

•&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Frame Relay over MPLS

•&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
PPP over MPLS

•&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
HDLC over MPLS


3.1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Ethernet over MPLS

O transporte do L2 funciona através do
encapsulamento Ethernet PDUs em pacotes MPLS e encaminha-os através da rede
MPLS. Cada PDU é transportado como um único pacote. As seguintes etapas
descrevem o processo de encapsular o PDU.


3.1.1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Ingress PE Router

•&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
O PE de entrada recebe o PDU e remove o
preamble, o delimitador do frame (SFD), e o frame check sequence (FCS). O resto do cabeçalho permanece o mesmo.

•&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
O PE copia o codigo de controle do cabeçalho,
mesmo que não seja usado, adiciona um label VC e um label do túnel LSP para o
roteamento normal do MPLS através do backbone. A rede roteia os dados usando o
tunnel LSP convencional do MPLS sem distinguir o tipo de tráfego.


3.1.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Egress PE Router

•&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
O PE de destino recebe o pacote e remote o label
do LSP, caso exista (Penultimo geralmente retira), retira o label de controle e
o label do VOCÊ;

•&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
O PE atualiza o cabeçalho se necessário e envia
o pacote para o CE associado.






4 &nbsp;&nbsp;&nbsp;&nbsp;
Cenário


4.1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Objetivo

Seis
roteadores (CE1, PE1, P1, P2, PE2 e CE2) são conectados formando um backbone
(PE1, P1, P2 e PE2) com dois roteadores de clientes conectados (CE1 e CE2).
Pede-se: 

Na
conexão entre o P1 e o P2 deverá existir o protocolo OSPF na área 0 somente
entre eles;

O
P1 e o P2 deverá prover uma VPN L2 com AToM entre o PE1 e o PE2. O PE1 e o PE2
deverão pertencer a mesma rede 12.12.12.0/24 através da conexão com P1 e P2;
Na
conexão entre o PE1 e o PE2 deverá existir o protocolo OSPF na área 0 somente
entre eles;
Deverá
ser configurado o MBGP no AS 1 entre o PE1 e o PE2 para exclusivamente a troca
de informações de VRF;
Deverá
ser usado o MPLS IP com LDP no backbone com a interface loopback 0 como
router-id;
Deverá
ser configurada uma VRF com nome VPN_A com RD e RT = 1:1 nas conexões do PE1 e
do PE2 com o CE1 e o CE2 respectivamente;
Deverá
ser habilitado o multicast no PE1 e no PE2 para o uso de multicast dentro da
VRF VPN_A. O grupo MDT da VPN_A deverá ser 232.0.0.1 com SSM habilitado no
backbone com o grupo default;
Dentro
da VRF, o CE1 é source de 224.1.1.1 e o CE2 é client. O RP deverá ser a
Loopback do CE2.



4.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Topologia








4.3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IOS
utilizados

•&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CE1,
PE1, P1, P2, PE2 e CE2– c7200-k91p-mz.122-25.S15.bin


4.4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Configuração
dos Roteadores


4.4.1&nbsp;&nbsp;&nbsp;
Configurações
do OSPF nos Backbones

Em todos os
roteadores configura-se o roteamento OSPF pelo comando “router ospf ” onde o “processo” é um numero do
processo OSPF. O roteador também possui um router ID único que geralmente é a
interface loopback ou então o maior endereço IP do roteador.

Para
adicionar interfaces deve-se usar o comando “network área ”.
Um roteador pode ter interfaces em áreas distintas, define-se cada área pelo
comando network.&nbsp;
Para o
roteador fazer vizinhança OSPF é necessário que a rede da interface esteja no
comando “network” e a interface não esteja configurada como “passive-interface”.&nbsp;

4.4.2&nbsp;&nbsp;&nbsp;
Configurações
do MPLS

&nbsp;Antes de
qualquer configuração, o Cisco Express forwarding deve ser habilitado com o
comando “ip cef”. Para habilitar o
MPLS no modo LDP, usa-se o comando global “mpls
label protocol ldp”. &nbsp;

4.4.3&nbsp;&nbsp;&nbsp; Configuração do MBGP &nbsp;

Para estabelecer uma VPN é necessário
configurar o MBGP para a troca de informações de prefixos de VPN. Pode-se
somente configurar o MBGP nos roteadores PEs da rede que possuem conexão com os
CEs, ou seja, conectados diretamente aos sites.
O MBGP funciona como o BGP, configura-se em
todos os roteadores pelo comando “router
bgp ” onde o “AS” é o Autonomous System do backbone. Dentro da
configuração de BGP adicionam-se os vizinhos estaticamente com o comando “neighbor  remote-as
”.
Adiciona-se o IP da interface loopback como
Router-ID pelo comando “bgp router-id
”.
Como os roteadores dentro do mesmo AS não
divulgarão as rotas IBGP entre eles, faz-se o full-mesh de conexão MBGP ou configuram-se
os roteadores centrais como Router-reflectors adicionando os demais roteadores
como clientes pelo comando “neighbor
 router-reflector-client”.
O MBGP é configurado dentro do protocolo BGP,
porém deve-se separar a família de roteamento com o comando “address-family vpnv4”. Para o envio de
prefixos das VPNs, deve-se habilitar o envio de community extendida com o
comando “neighbor  send-community
extended”.
Todos os recursos como route-map,
next-hop-self, router-reflector, etc. podem ser configurados dentro da família VPNv4
para manipular ou resolver problemas de roteamento.&nbsp;

4.4.4&nbsp;&nbsp;&nbsp;
Criando
uma VPN VRF no BGP

Após todos os roteadores PEs da rede possuem
conectividade MBGP, ou diretamente ou por router-reflector, cria-se a VPN com o
comando “ip vrf ”,
dentro desse comando ficam os parâmentros de marcação da VPN e das communities
associadas aos prefixos daquela VPN. Configura-se o Route-Distinguisher da VPN,
que deve ser único na rede, com comando “rd
:”, e também cria-se a&nbsp; community que será exportada para aqueles
prefixos de rede com o comando “route-target
 :”, onde “import”
significa importar as rotas e “export” exportar as rotas.
Cria-se então uma address-family dentro do BGP
com o comando “address-family ipv4 vrf ”
com o mesmo nome da VPN criada no “ip vrf” fora do roteamento BGP. Dentro dessa
address-family são configuradas as redes que serão redistribuídas para os
outros sites. Para divulgar as redes é necessário que a rede exista na tabela
de roteamento interna e, ou adicionar o comando “network  mask ” ou redistribuindo rotas para
o MBGP com o comando “redistribute”, que pode ser vinculado à um route-map para definir
exatamente as rotas que serão divulgadas de um protocolo para outros sites.
Enfim, para que uma interface conectada ao CE faça parte da VPN BGP,
usa-se o comando “ip vrf forwarding
” dentro da interface.&nbsp;

4.4.5&nbsp;&nbsp;&nbsp;
Configuração do Túnel AToM&nbsp;

O tunnel L2 AToM é configurado na interface do
PE conectada diretamente ao CE com o comando “xconnect   pw-class ”.
O ID do VC tem que ser o mesmo nos dois PEs. O  é criado com o
comando global “pseudowire-class
” Dentro da configuração dessa classe são adicionadas as
informações do túnel como “encapsulation
mpls” para o tipo de encapsulamento.&nbsp;

4.4.6&nbsp;&nbsp;&nbsp;
Configuração
do Multicast no Backbone com SSM

É necessário configurar o roteamento multicast
no roteador com o comando “ip
multicast-routing” e também dentro das VPNs com o comando “ip multicast-routing vrf ”
aplicado nos PEs.
Para definir o escopo do Souce Specific
Multicast usa-se uma ACL definindo o escopo e aplica-a no comando “ip pim ssm range ”, ou então
usa-se o default que é 232.0.0.0.&nbsp;

4.4.7&nbsp;&nbsp;&nbsp;
Configuração
do Multicast na VPN&nbsp;

Antes de configurar o PIM é necessário
configurar o roteamento multicast no roteador com o comando “ip multicast-routing”. No PIM a
configuração para o sparse mode é feita a configuração “ip pim sparse-mode” nas interfaces com os roteadores que trafegam
multicast. O Sparse mode necessita de um Rendevouz Point.&nbsp;
&nbsp;A
configuração de Rendevouz Point estático é feita pelo comando “ip pim rp-address ”.&nbsp;

4.4.8&nbsp;&nbsp;&nbsp;
Configurações
do IGMP&nbsp;

O IGMP é configurado em todas as interfaces que
estão com o multicast PIM configurado. Caso algum host conectado ao roteador
enviar um trafego de “join multicast” o roteador automaticamente passará para o
Source daquele grupo, caso exista.
Nesse exemplo pode-se utilizar o comando “ip igmp join-group ” para enviar uma solicitação de join no grupo multicast.&nbsp;

4.6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Comandos
Importantes de Verificação





PE1#show
ip mroute vrf VPN_A

IP
Multicast Routing Table

Flags: D
- Dense, S - Sparse, B - Bidir Group, s - SSM
Group, C - Connected,

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; L - Local, P -
Pruned, R - RP-bit set, F - Register flag,

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; T - SPT-bit set, J - Join SPT, M - MSDP
created entry,

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; X - Proxy Join Timer Running, A -
Candidate for MSDP Advertisement,

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; U - URD, I - Received Source Specific
Host Report, Z - Multicast Tunnel

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Y - Joined MDT-data group, y - Sending
to MDT-data group

Outgoing
interface flags: H - Hardware switched, A - Assert winner

&nbsp;Timers: Uptime/Expires

&nbsp;Interface state: Interface, Next-Hop or VCD,
State/Mode



(*,
224.1.1.1), 00:00:16/stopped, RP 20.20.20.1, flags: SPF

&nbsp; Incoming interface: Tunnel0, RPF nbr 2.2.2.2

&nbsp; Outgoing interface list: Null



(10.10.10.1,
224.1.1.1), 00:00:16/00:03:23, flags: FT

&nbsp; Incoming interface: FastEthernet0/0, RPF nbr
0.0.0.0

&nbsp; Outgoing interface list:

&nbsp;&nbsp;&nbsp; Tunnel0, Forward/Sparse, 00:00:16/00:03:13



(*,
224.0.1.40), 00:48:47/00:02:59, RP 20.20.20.1, flags: SJCL

&nbsp; Incoming interface: Tunnel0, RPF nbr 2.2.2.2

&nbsp; Outgoing interface list:

&nbsp;&nbsp;&nbsp; FastEthernet0/0, Forward/Sparse,
00:48:14/00:02:59





P1#show mpls l2transport vc detail 

Local interface: Fa0/0 up, line protocol up,
Ethernet up

&nbsp;
Destination address: 22.22.22.22, VC ID: 100, VC status: up

&nbsp;&nbsp;&nbsp;
Output interface: Fa1/0, imposed label stack {16}

&nbsp;&nbsp;&nbsp;
Preferred path: not configured&nbsp; 

&nbsp;&nbsp;&nbsp; Default
path: active

&nbsp;&nbsp;&nbsp;
Tunnel label: imp-null, next hop 12.12.12.2

&nbsp; Create
time: 04:10:24, last status change time: 04:05:47

&nbsp;
Signaling protocol: LDP, peer 22.22.22.22:0 up

&nbsp;&nbsp;&nbsp; MPLS
VC labels: local 16, remote 16 

&nbsp;&nbsp;&nbsp; Group
ID: local 0, remote 0

&nbsp;&nbsp;&nbsp; MTU:
local 1500, remote 1500

&nbsp;&nbsp;&nbsp;
Remote interface description: 

&nbsp;
Sequencing: receive disabled, send disabled

&nbsp; VC
statistics:

&nbsp;&nbsp;&nbsp;
packet totals: receive 8301, send 8332

&nbsp;&nbsp;&nbsp; byte
totals:&nbsp;&nbsp; receive 847189, send 1033403

&nbsp;&nbsp;&nbsp;
packet drops:&nbsp; receive 0, send 20






5
&nbsp;&nbsp;&nbsp;&nbsp; Configuração




5.1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CE1


!

ip
multicast-routing 

!

!

interface
FastEthernet0/0

&nbsp;ip address 10.10.10.1 255.255.255.0

&nbsp;ip pim sparse-mode

!

ip route
0.0.0.0 0.0.0.0 10.10.10.254

!

ip pim
rp-address 20.20.20.1

!



5.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
PE1


!

ip cef

!

ip vrf VPN_A

&nbsp;rd 1:1

&nbsp;route-target export 1:1

&nbsp;route-target import 1:1

&nbsp;mdt default 232.0.0.1



!

ip multicast-routing 

ip multicast-routing vrf
VPN_A 

!

mpls label protocol ldp

!

interface Loopback0

&nbsp;ip
address 1.1.1.1 255.255.255.255

&nbsp;ip pim
sparse-mode

!

interface FastEthernet0/0

&nbsp;ip vrf forwarding VPN_A

&nbsp;ip
address 10.10.10.254 255.255.255.0

&nbsp;ip pim
sparse-mode

!

interface FastEthernet1/0

&nbsp;ip
address 12.12.12.1 255.255.255.0

&nbsp;ip pim sparse-mode

&nbsp;mpls mtu
1524

&nbsp;mpls ip

!

router ospf 1

&nbsp;router-id 1.1.1.1

&nbsp;network
1.1.1.1 0.0.0.0 area 0

&nbsp;network
12.12.12.1 0.0.0.0 area 0

!

router bgp 1

&nbsp;bgp
router-id 1.1.1.1

&nbsp;neighbor
2.2.2.2 remote-as 1

&nbsp;neighbor
2.2.2.2 update-source Loopback0

&nbsp;!

&nbsp;address-family vpnv4

&nbsp;neighbor
2.2.2.2 activate

&nbsp;neighbor
2.2.2.2 send-community extended

!

&nbsp;address-family ipv4 vrf VPN_A

&nbsp;redistribute connected

!

ip pim ssm default

!

ip pim vrf VPN_A rp-address
20.20.20.1

!





5.3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
P1


!

ip cef

!

mpls
label protocol ldp

!

pseudowire-class ATOM

&nbsp;encapsulation mpls

!

!

!

interface
Loopback0

&nbsp;ip address 11.11.11.11 255.255.255.255

!

interface
FastEthernet0/0

&nbsp;xconnect 22.22.22.22
100 pw-class ATOM

!

interface
FastEthernet1/0

&nbsp;ip address 12.12.12.1 255.255.255.0

&nbsp;mpls mtu 1524

&nbsp;mpls ip

!

router
ospf 1

&nbsp;router-id 11.11.11.11

&nbsp;network 11.11.11.11 0.0.0.0 area 0

&nbsp;network 12.12.12.1 0.0.0.0 area 0

!



5.4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
P2


!

ip cef

!

mpls
label protocol ldp

!

pseudowire-class ATOM

&nbsp;encapsulation mpls

!

!

interface
Loopback0

&nbsp;ip address 22.22.22.22 255.255.255.255

!

interface
FastEthernet0/0

&nbsp;xconnect 11.11.11.11
100 pw-class ATOM

!

interface
FastEthernet1/0

&nbsp;ip address 12.12.12.2 255.255.255.0

&nbsp;mpls mtu 1524

&nbsp;mpls ip

!

router
ospf 1

&nbsp;router-id 22.22.22.22

&nbsp;network 12.12.12.2 0.0.0.0 area 0

&nbsp;network 22.22.22.22 0.0.0.0 area 0

!



5.5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
PE2


!

ip cef

!

ip vrf
VPN_A

&nbsp;rd 1:1

&nbsp;route-target export 1:1

&nbsp;route-target import 1:1

&nbsp;mdt default 232.0.0.1



!

ip
multicast-routing 

ip
multicast-routing vrf VPN_A 

!

mpls
label protocol ldp

!

!

interface
Loopback0

&nbsp;ip address 2.2.2.2 255.255.255.255

&nbsp;ip pim sparse-mode

!

interface
FastEthernet0/0

&nbsp;ip vrf forwarding
VPN_A

&nbsp;ip address 20.20.20.254 255.255.255.0

&nbsp;ip pim sparse-mode

!

interface
FastEthernet1/0

&nbsp;ip address 12.12.12.2 255.255.255.0

&nbsp;ip pim sparse-mode

&nbsp;mpls mtu 1524

&nbsp;mpls ip

!

router
ospf 1

&nbsp;router-id 2.2.2.2

&nbsp;network 2.2.2.2 0.0.0.0 area 0

&nbsp;network 12.12.12.2 0.0.0.0 area 0

!

router
bgp 1

&nbsp;bgp router-id 2.2.2.2

&nbsp;neighbor 1.1.1.1 remote-as 1

&nbsp;neighbor 1.1.1.1 update-source Loopback0

&nbsp;!

&nbsp;address-family vpnv4

&nbsp;neighbor 1.1.1.1 activate

&nbsp;neighbor 1.1.1.1 send-community extended

!

&nbsp;address-family ipv4
vrf VPN_A

&nbsp;redistribute connected

!

ip pim ssm default

!

ip pim vrf VPN_A rp-address 20.20.20.1

!



5.6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
CE2


!

ip
multicast-routing 

!

!

interface
FastEthernet0/0

&nbsp;ip address 20.20.20.1 255.255.255.0

&nbsp;ip igmp join 224.1.1.1

&nbsp;ip pim sparse-mode

!

ip route
0.0.0.0 0.0.0.0 20.20.20.254

!

ip pim
rp-address 20.20.20.1



!