quinta-feira, 29 de maio de 2014

Servidor DNS no Sistema Operacional Linux

Olá Pessoal.

O DNS é um dos serviços mais importantes na Internet porque é responsável pela tradução dos endereços nominais (nomes) em números (IPs) e vice-versa (resolução reversa). Os nomes são mais fáceis de serem memorizados pelas pessoas e esse serviço será ainda mais importante com a disseminação do IPv6 que possui endereços mais complexos. Esse serviço pode ser implementado no Linux através do BIND. Para exemplificar seu processo de configuração em distribuições baseadas no Debian irei utilizar o cenário abaixo que pode ser facilmente reproduzido no VirtualBox. 


A primeira etapa consiste na instalação do pacote "bind9" para que o Linux possa ser posteriormente configurado como servidor primário DNS na rede. Essa tarefa é simples e rápida através do APT.

root@ns1:/# apt-get install bind9

Os arquivos de configuração ficam armazenados em "/etc/bind". No arquivo de configuração "/etc/bind/named.conf.local" são realizadas as primeiras configurações da zona direta de domínio (forward) e da zona reversa. 

#--- em /etc/bind/named.conf.local
zone    "nome.com.br"   
{
        type master;
        file    "/etc/bind/nome.com.br.forward";
        allow-transfer { 192.168.221.202; };
};

zone    "221.168.192.in-addr.arpa"        
{
        type master;
        file    "/etc/bind/nome.com.br.reverse";
        allow-transfer { 192.168.221.202; };
};

A primeira seção do arquivo de configuração faz referência à zona direta, enquanto que a segunda seção faz referência à zona reversa. O parâmetro type informa que esse servidor será mestre e o parâmetro allow-transfer permite a troca de informações com outro servidor que configuraremos mais adiante. O parâmetro file informa o caminho onde podem ser encontrados os arquivos de configuração das zonas direta e reversa. Respeitando os caminhos informados na configuração anterior, devem ser criados os arquivos das zonas direta e reversa. 

É recomendado gerar esses arquivos a partir de outros já existentes para evitar erros de sintaxe. O arquivo "/etc/bind.db.local" pode servir como modelo de zona direta, enquanto que o arquivo "/etc/bind/db.127" pode servir como modelo de zona reversa. 

root@ns1:/# cp /etc/bind/db.local /etc/bind/nome.com.br.forward
root@ns1:/# cp /etc/bind/db.127   /etc/bind/nome.com.br.reverse 

Para o exemplo da topologia apresentada na imagem, a configuração do arquivo da zona direta deve ficar da seguinte maneira:

;--- /etc/bind/nome.com.br.forward
; BIND - Zona Direta (nome.com.br)
;---
$TTL    604800
@       IN      SOA     ns1.nome.com.br. root.nome.com.br. (
                        2014051801       ; Serial
                            604800       ; Refresh
                             86400       ; Retry
                           2419200       ; Expire
                            604800 )     ; Negative Cache TTL
;
@       IN     NS       ns1.nome.com.br.
@       IN NS ns2.nome.com.br.
gateway IN A 192.168.221.1
client IN A 192.168.221.37
ns1 IN A 192.168.221.201
ns2 IN A 192.168.221.202
router IN CNAME gateway
winxp IN CNAME client

O registro NS faz referência aos próprios servidores DNS responsáveis pelo domínio (autoritativo), que são ns1 e ns2 neste exemplo. Os registros A são mapeamentos diretos entre nomes e endereços IPv4, sendo que para endereços IPv6 os registros são AAAA (quad-A). Os registros CNAME são apelidos que podem ficar associados com nomes que já existem, por exemplo: gateway <> router.

A configuração do arquivo da zona reversa fica da seguinte maneira:

;--- /etc/bind/nome.com.br.reverse
; BIND - Zona Reversa (nome.com.br)
;---
$TTL    604800
@       IN      SOA     ns1.nome.com.br. root.nome.com.br. (
                        2014051801       ; Serial
                            604800       ; Refresh
                             86400       ; Retry
                           2419200       ; Expire
                            604800 )     ; Negative Cache TTL
;
@ IN  NS ns1.nome.com.br.
@ IN NS ns2.nome.com.br.
1 IN PTR gateway.nome.com.br.
37 IN PTR client.nome.com.br.
201 IN PTR ns1.nome.com.br.
202 IN PTR ns2.nome.com.br.

Os registros PTR fazem referência ao mapeamento reverso, por isso as referidas linhas começam com um número referente a porção do endereço IP que remete ao host informado na sequência. Por exemplo, o host 37 dentro da rede 192.168.221.0/24 (192.168.221.37) responde pelo nome client.nome.com.br.

Antes de tentar inicializar o serviço é importante fazer uma verificação de erros de sintaxe nos arquivos de configuração através das ferramentas named-checkconf e named-checkzone. Se algum erro for indicado, verifique novamente os arquivos. 

root@ns1:/# named-checkconf /etc/bind/named.conf.local
root@ns1:/# named-checkzone nome.com.br /etc/bind/nome.com.br.forward
root@ns1:/# named-checkzone 221.168.192.in-addr.arpa /etc/bind/nome.com.br.reverse

Por fim, depois de configurado o servidor, basta iniciar o serviço para validar todas as configurações realizadas anteriormente. A partir de agora, todos os clientes da rede já podem utilizar o servidor de nomes interno. 

root@ns1:/# service bind9 start
[ ok ] Starting domain name service...: bind9.

Obs.: Quando um novo serviço é instalado no Debian, ele passa a ser automaticamente inicializado em caso de boot do servidor. A ferramenta update-rc.d pode ser utilizada para remover/adicionar serviços no processo de inicialização automática, por ex.: "update-rc.d -f bind9 remove" ou "update-rc.d bind9 defaults".

O arquivo local "/etc/resolv.conf" deve ser atualizado com o endereço localhost como próprio servidor de nomes. Estamos nos adiantando ao informar o servidor secundário (192.168.221.201) que será configurado na sequência. 

#--- em /etc/resolv.conf
search nome.com.br
nameserver 127.0.0.1
nameserver 192.168.221.202

Há várias ferramentas de diagnóstico que podem ser utilizadas para verificar se o servidor DNS está operando corretamente. Através do comando dig é possível buscar os registros A e PTR (reverso). É recomendado que o leitor consulte as ferramentas apresentadas abaixo:

root@Host:/# dig gateway.nome.com.br
root@Host:/# dig –x 192.168.221.1
root@Host:/# nslookup <hostname|IP>
root@Host:/# host     <hostname|IP>

Uma vez configurado e funcionando o servidor mestre ns1, configurar o servidor escravo ns2 é bastante simples porque os arquivos de configuração das zonas direta e reversa serão replicados. Primeiramente vamos instalar o bind no servidor seguindo o mesmo procedimento visto anteriormente:

root@ns2:/# apt-get install bind9

No arquivo de configuração "/etc/bind/named.conf.local" devem ser informada as zonas direta e reversa, fazendo referência ao master. Observem que os arquivos das zonas não podem ficar no diretório /etc/bind, como fizemos anteriormente com o servidor master onde o arquivo foi criado e editado manualmente. Ao informar apenas os nomes dos arquivos das zonas (destaque em amarelo), sem nenhum caminho, o sistema se encarrega de armazená-los no diretório /var/cache/bind, onde devem ficar os arquivos dinâmicos (escritos pelo sistema) porque existe permissão de escrita. Pronto, as demais configurações serão sincronizada a partir do master. :-)

zone    "nome.com.br"   
{
        type slave;
        file    "nome.com.br.forward";
        masters { 192.168.221.201; };
};

zone   "221.168.192.in-addr.arpa"        
{
       type slave;
       file    "nome.com.br.reverse";
       masters { 192.168.221.201; };
};

O arquivo local "etc/resolv.conf" deve ser atualizado com o endereço localhost como próprio servidor de nomes. Reparem que estamos informando o servidor master como secundário, já que ns2 também é um servidor de nomes. 

#--- em /etc/resolv.conf
search nome.com.br
nameserver 127.0.0.1
nameserver 192.168.221.201

Feito isso já existem dois servidores DNS instalados no ambiente e que respondem pelo domínio nome.com.br (servidores autoritativos). Os dois servidores irão sincronizar todos os registros de nomes com os servidores raízes espalhados pela Internet e todas as máquinas da rede local farão suas consultas DNS no contexto local, evitando consultas externas que têm maior latência. 

Abraço.

Samuel.

quarta-feira, 21 de maio de 2014

Configuração de Relay-Agent em Roteadores Linux

Olá Pessoal.

No processo de comunicação do DHCP, os clientes fazem a busca por um ou mais servidores através do envio de mensagems de broadcast (com o endereço de origem 0.0.0.0/32 ou ::0/128) para alcançar toda a rede local na procura por algum servidor DHCP. O "problema" em ambientes com múltiplas sub-redes que possuem um único servidor DHCP centralizado é que a propagação do tráfego de broadcast nas sub-redes cessa nos seus respectivos gateways (na interface de um roteador), uma vez que roteadores não têm permissão para propagar broadcast.

Em situações em que existem diferentes sub-redes atrás de um roteador e um único servidor centralizado para distribuir os endereços via DHCP, além de configurar o servidor com os múltiplos escopos que ele deverá distribuir, é também necessário configurar um relay-agent DHCP. O relay-agent é um serviço configurado manualmente que redireciona o tráfego de broadcast que chega em uma (ou mais) interface(s) para um host específico como tráfego unicast. 

A configuração do relay-agent em roteadores Cisco é muito simples e pode ser realizada através do comando "ip helper-address <IP-HOST>" na interface que irá receber broadcast. O leitor interessado nessa configuração em roteadores Cisco pode encontrar um exemplo em outro artigo intitulado "Configuração de Switches Multi-Layer (Layer-3)"

O relay-agent pode ser facilmente implementado em ambientes que possuem roteadores Linux. Especificamente em distribuições baseadas no Debian, para configurar o serviço Relay-Agent é necessário instalar o pacote "dhcp-helper":

root@LinuxRouter:/# apt-get install dhcp-helper

Feito isso, basta realizar as configurações através do arquivo "/etc/default/dhcp-helper". Por padrão, o serviço irá inicializar fazendo o relay do broadcast na interface eth0, por isso é necessário personalizar a configuração para reproduzir a necessidade do seu ambiente. Para exemplificar o conteúdo do arquivo de configuração, consideremos o cenário da figura abaixo que pode ser facilmente reproduzido através do VirtualBox:


#--- em /etc/default/dhcp-helper
#
# You will need at least "-s" or
# "-b" so that dhcp-helper know where
# to relay DHCP requests.

DHCPHELPER_OPTS="-s 172.19.0.1 -e eth0" 

A opção -s faz referência ao endereço do(s) servidor(es) em que o tráfego de broadcast será redirecionado como unicast. O administrador poderia utilizar a opção -b para indicar ao relay-agent que todo tráfego de broadcast deveria ser encaminhado para a interface conectada na rede em que existe o servidor DHCP, assim seria desnecessário informar um endereço específico. No entanto essa prática implicaria em mais broadcast na rede, por isso o ideal é utilizar a opção -s e informar o endereço específico do servidor. A opção -e é utilizada para excluir a escuta em alguma interface específica em que não é desejado o serviço de relay do tráfego broadcast, por exemplo na Internet ou em alguma sub-rede endereçada estaticamente. A opção -i especifica em qual(is) interface(is) haverá escuta do tráfego broadcast, destacando que a omissão dessa opção implica na escuta em todas as interfaces (exceto naquelas excluídas através da opção -e).

O serviço pode ser inicializado através do comando abaixo:

root@LinuxRouter:/# service dhcp-helper start
Starting DHCP relay agent: dhcp-helper.

Para informações mais detalhadas, consulte o manual do serviço via linha de comando:

root@LinuxRouter:/# man dhcp-helper

Esse é um recurso simples e bastante útil.

Abraço.

Samuel.

quinta-feira, 15 de maio de 2014

Configuração de Servidor DHCP: Cisco x Linux

Olá Pessoal.

O tradicional serviço DHCP (Dynamic Host Configuration Protocol) é definido na RFC 2131 e diz respeito à distribuição automática de endereços em uma rede TCP/IPv4 através de um servidor. É nesse servidor que o administrador irá criar um escopo definindo o intervalo de endereços que será distribuído para as máquinas, bem como outras configurações importantes: gateway da rede, servidores de resolução de nomes (DNS), opções, etc.

O servidor fica responsável por manter uma tabela com o registro dos clientes (MAC), seus respectivos endereços atribuídos (IP) e seu tempo de empréstimo (lease). Uma vez que o servidor mantém essa tabela com o "estado" dos clientes associando os endereços físicos das máquinas (MAC) com os endereços lógicos (IP) atribuídos, então dizemos que esse é um serviço de natureza stateful, ou seja, é mantido um registro de estado.

A sua configuração através de um roteador Cisco é bastante simples, bastando a entrada de alguns poucos comandos para fazê-lo. Vamos observar o cenário da figura abaixo em que temos uma rede 192.168.221.0/24, sendo que todas as máquinas estarão configuradas para obter o endereço dinamicamente e o roteador será responsável por executar o serviço DHCP. As configurações necessárias seriam as seguintes:




01. Router(config)# ip dhcp excluded-address 192.168.221.1 192.168.221.30
02. Router(config)# ip dhcp pool NOME-ESCOPO
03. Router(config-dhcp)# network 192.168.221.0 255.255.255.0
04. Router(config-dhcp)# default-router 192.168.221.1
05. Router(config-dhcp)# dns-server 192.168.221.2 208.67.222.222
06. Router(config-dhcp)# domain-name nome.com.br
07. Router(config-dhcp)# lease 1

Na primeira linha definimos quis endereços devem ser excluídos do escopo que será posteriormente criado, uma vez que esses endereços serão atribuídos estaticamente porque são reservados para os servidores. Na segunda linha foi dado um nome para o escopo que irá compreender os endereços da rede informada na terceira linha, sendo que nas linhas 4 e 5 são informados os endereços que as máquinas deverão utilizar como gateway e DNS. A linha 6 informa o nome de domínio que deve ser anexado como sufixo aos nomes. A linha 7 poderia ser omitida porque indica que a duração do empréstimo é de 1 dia (padrão). Pois bem, simples até aqui!

Agora vamos considerar que no cenário anterior o roteador não ficará responsável pela execução do serviço DHCP, sendo que um dos servidores está instalado com Linux Debian e deverá assumir essa função, ou seja, será um servidor DHCP que estará configurado na rede com o IP 192.168.221.5. A boa notícia é que esse procedimento no Linux também é bastante simples, então vamos à configuração:

1. Instalação do Serviço DHCP

A primeira etapa consiste na instalação do pacote "isc-dhcp-server" para que o Linux possa ser posteriormente configurado como servidor DHCP na rede. Essa tarefa é simples e rápida através do APT (Debian):

root@LinuxServer:/# apt-get install isc-dhcp-server

2. Ativar Interfaces p/ Responder Requisições DHCP

A segunda etapa é informar em qual(is) interface(s) o servidor irá responder requisições dos clientes da rede, através da edição do arquivo "/etc/default/isc-dhcp-server".

#--- em /etc/default/isc-dhcp-server
(...) Conteúdo Omitido
#On what interfaces should the DHCP server (dhcpd) serve DHCP requests?
#Separate multiple interfaces with spaces, e.g. "eth0 eth1".

INTERFACES="eth1"

3. Configurar o Servidor DHCP

A etapa mais importante consiste na configuração do servidor DHCP propriamente dito, tarefa que é realizada através da edição do arquivo "/etc/dhcp/dhcpd.conf".

#--- em /etc/dhcp/dhcpd.conf
ddns-update-style none;
default-lease-time 86400;
max-lease-time 604800;
authoritative;

subnet 192.168.221.100 netmask 255.255.255.0
{
  range 192.168.221.31 192.168.221.199;
  option routers 192.168.221.1;
  option domain-name-servers 192.168.221.2, 208.67.222.222;
  option domain-name "nome.com.br";
}

Obs.: Os tempos são configurados em segundos, ou seja, um empréstimo de 86400s equivale a 1 dia. O tempo padrão do empréstimo será o valor do default-lease-time, no entanto as interfaces podem solicitar um determinado tempo do empréstimo que não pode ultrapassar o valor de max-lease-time (604800s = 1 semana).

4. Reserva de Empréstimo (Opcional)

Opcionalmente, o administrador da rede pode reservar/fixar o lease (empréstimo) de um endereço IP específico para um determinado cliente através da associação com o seu endereço físico (MAC).

#--- em /etc/dhcp/dhcpd.conf
host NOME
{
  hardware ethernet 00:00:00:00:00:0a;
  fixed-address 192.168.221.37;
}

5. Manipulação do Serviço DHCP

Por fim, depois de configurado o servidor, basta iniciar o serviço para realizar a distribuição dinâmica de endereços via DHCP. O comando abaixo pode ser inserido no arquivo "/etc/rc.local" para que o serviço DHCP seja iniciado automaticamente em caso de boot do servidor.

root@LinuxServer:/# service isc-dhcp-server start
[ ok ] Starting ISC DHCP Server: dhcpd.

6. Visualização de Endereços Concedidos (Lease)

O administrador da rede pode visualizar a relação de todos os endereços concedidos pelo servidor DHCP, listando o conteúdo do arquivo "/var/lib/dhcp/dhcpd.leases".

root@LinuxServer:/# cat /var/lib/dhcp/dhcpd.leases
(...) Saída Omitida

Para obter informações detalhadas, consulte o manual via linha de comando:

root@LinuxServer:/# man dhcpd.conf

Abraço.

Samuel.

sexta-feira, 9 de maio de 2014

Palestra Sobre PMBOK na UNIMEP

Olá Pessoal.

Na próxima semana, dia 14/05/2013 (quarta-feira), será realizada uma palestra na UNIMEP intitulada "Fundamentos de Geranciamento de Projetos". O objetivo do evento é apresentar os principais tópicos do PMBOK que são frequentemente abordados nas principais certificações da área de Gestão de Projetos



O evento é gratuito e aberto também para participação da comunidade externa! Todos os leitores do blog estão convidados, participem e tragam seus colegas...

> Palestrante: Patrícia Azevedo (LAN University)

Graduada em Análise de Sistemas – PUC de Campinas
Instrutora Homologada da Academia SAP SD
Certificada PMP/PMI (Metodologia PMBOK)
Gestão de Projetos - Fundação Dom Cabral
SAP Pricing SD - Sales ans Distribution

> Conteúdo Abordado:

Esta palestra fará um breve "passeio" pelos tópicos do PMBOK que são abordados na formação e preparação para certificações na área, introduzindo o participante no complexo mundo do Geranciamento de Projetos. O PBMOK é um guia/livro publicado pelo PMI (Project Management Institute) que apresenta as melhores práticas de gerenciamento de projetos. 

> Data e Local do Evento:


UNIMEP - Universidade Metodista de Piracicaba
Rodovia do Açucar, Km 156 - Piracicaba (SP)
Campus Taquaral - Auditório Verde - Bloco 02
Informações: (19) 3124.1684
14/05/2013 às 19h30 

Abraço.

Samuel.

segunda-feira, 5 de maio de 2014

Fundamentos de VRF na Virtualização de Roteadores

Olá Pessoal.

Esse artigo apresenta os conceitos básicos da tecnologia VRF (Virtual Routing and Forwarding) para fins de virtualização de tabelas de roteamento. De maneira bastante simplista podemos começar pensando da seguinte maneira: assim como VLAN é uma tecnologia para virtualização de switches (layer 2), VRF é uma tecnologia para virtualização de roteadores (layer 3). 

A tecnologia VRF é comumente utilizada por provedores na oferta do serviço VPN/MPLS para conectividade dos seus clientes através de um núcleo comum de equipamentos de grande porte, o que permite o compartilhamento organizado da sua infraestrutura. Com VRF é possível criar diferentes tabelas de roteamento lógicas em um mesmo roteador físico, o que explica a possibilidade de conexão de diversos clientes através de equipamentos compartilhados com garantia de que haverá isolamento total da visualização da topologia da rede e, consequentemente, do tráfego de dados. 

Outra vantagem é que, uma vez que as tabelas de roteamento são logicamente independentes, é possível configurar endereços com sobreposição (overlap) entre o roteador de borda da operadora (PE) e o roteador de borda do cliente (CE), o que é interessante quando os clientes utilizam endereços comuns, algo que ocorre com os endereços privados da RFC 1918 (10/8, 172.16/12 e 192.168/16). 

Para exemplificar o processo de configuração de VRFs estaremos utilizando como base o cenário apresentado abaixo. O PE representa o roteador de borda da operadora que é um equipamento comum a dois clientes, sendo que cada cliente está isolado através de uma VRF lógica que contempla os equipamentos separados nos quadros cinza e verde. Reparem que a rede entre o provedor e os clientes é igual (192.168.0.0/30), o que seria impossível de configurar em situação normal porque o roteador acusaria erro de sobreposição de endereços nas interfaces f0/0 e f1/0.


O processo de configuração do VRF e separação das tabelas de roteamento lógicas é bastante simples nesse exemplo. Basta criar as VRFs e então associar cada interface física (ou sub-interface lógica) com sua respectiva VRF. Ao fazê-lo, o roteador passará a trabalhar com múltiplas tabelas de roteamento distintas, cada uma identificada por seu nome lógico. 

01. PE(config)# ip vrf CINZA
02. PE(config-vrf)# rd 1:1
03. PE(config-vrf)# ip vrf VERDE
04. PE(config-vrf)# rd 2:2
05. PE(config-vrf)# exit
06. PE(config)# int f0/0
07. PE(config-if)# ip vrf forwarding CINZA
08. PE(config-if)# ip address 192.168.0.1 255.255.255.252
09. PE(config-if)# no shut
10. PE(config-if)# int f1/0
11. PE(config-if)# ip vrf forwarding VERDE
12. PE(config-if)# ip address 192.168.0.1 255.255.255.252
13. PE(config-if)# no shut
14. PE(config-if)# int lo1
15. PE(config-if)# ip vrf forwarding CINZA
16. PE(config-if)# ip address 172.30.0.1 255.255.0.0
17. PE(config-if)# int lo2
18. PE(config-if)# ip vrf forwarding VERDE
19. PE(config-if)# ip address 172.20.0.1 255.255.0.0 

Nas linhas de 01 a 04 foram criadas duas VRFs denominadas CINZA e VERDE, sendo que o nome e o valor RD (Route Distinguisher) são válidos localmente. No PE configurei duas interfaces de loopback (linhas de 14 a 19), uma associada com cada cliente. Fazer isso é interessante caso o leitor queira aproveitar o cenário para configurar roteamento entre os roteadores e observar o aprendizado de rotas que ocorre em cada cliente.

O cliente da "VRF CINZA" aprende a rede 172.30.0.0/16, enquanto que o cliente da "VRF VERDE" aprende a rede 172.20.0.0/16, o que confirma que o isolamento lógico está funcionando. Tomando como exemplo o protocolo EIGRP, a configuração dos roteadores CE não muda nada (eles sequer conhecem as VRFs), mas no PE é necessário usar o recurso address-family (AF) para especificar a VRF. O parâmetro "Autonomous-System" deve referenciar o AS do respectivo CE:

PE(config)# router eigrp 65001
PE(config-router)# address-family ipv4 vrf CINZA
PE(config-router)# autonomous-system 1
PE(config-router-af)# network 192.168.0.0
PE(config-router-af)# network 172.30.0.0
PE(config-router-af)# exit
PE(config-router)# address-family ipv4 vrf VERDE
PE(config-router-af)# autonomous-system 2
PE(config-router-af)# network 192.168.0.0
PE(config-router-af)# network 172.20.0.0
PE(config-router-af)# exit

CE1-CINZA(config)# router eigrp 1
CE1-CINZA(config-router)# network 192.168.0.0
CE1-CINZA(config-router)# exit

CE2-VERDE(config)# router eigrp 2
CE2-VERDE(config-router)# network 192.168.0.0
CE2-VERDE(config-router)# exit

Os roteadores CE1-CINZA e CE2-VERDE não precisam de nenhuma configuração adicional, já que eles não têm ciência da existência das VRFs lógicas em PE. No entanto, para o PE é necessário anexar o parâmetro "vrf NOME" nos principais comandos de manipualação e diagnóstico de rotas e hosts, a exemplo dos comandos "ip route" e "ping". As saídas abaixo trazem a alguns comandos básicos:

!--- Visualização da VRF CINZA
PE# show ip vrf CINZA
  Name                             Default RD          Interfaces
  CINZA                            1:1                 Lo1
                                                       Fa0/0
!--- Visualização da VRF VERDE
PE# show ip vrf VERDE
  Name                             Default RD          Interfaces
  VERDE                            2:2                 Lo2
                                                       Fa1/0
!--- Visualização da Tabela de Rotas da VRF CINZA
PE# show ip route vrf CINZA
Routing Table: CINZA
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C    172.30.0.0/16 is directly connected, Loopback1
     192.168.0.0/30 is subnetted, 1 subnets
C       192.168.0.0 is directly connected, FastEthernet0/0

!--- Visualização da Tabela de Rotas da VRF VERDE
PE# show ip route vrf VERDE
Routing Table: VERDE
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C    172.20.0.0/16 is directly connected, Loopback2
     192.168.0.0/30 is subnetted, 1 subnets
C       192.168.0.0 is directly connected, FastEthernet1/0

!--- Exemplo de Uso do Ping na VRF CINZA
PE# ping vrf CINZA 192.168.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms

Caso o leitor tenha mais interesse no assunto e queira se aprofundar através de um exemplo realista da aplicação dessa tecnologia em provedores (oferta de VPN/MPLS), sugiro a leitura de outro artigo que escrevi há algum tempo intitulado "Configuração da Nuvem MPLS em Provedores".

Abraço.

Samuel.