Este documento descreve como configurar VPNs de Camada 3 Dinâmica (L3 - Dynamic Layer 3) com o recurso de túneis de Encapsulamento de Roteamento Genérico Multiponto (mGRE - Generic Routing Encapsulation).
Antes de configurar VPNs L3 dinâmicas com o recurso de túneis mGRE, certifique-se de que a VPN MPLS (Multiprotocol Label Switching) esteja configurada e funcione corretamente e de que a conectividade fim-a-fim esteja estabelecida para a rede IPV4.
As informações neste documento são baseadas nestas versões de software e hardware:
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
O recurso VPNs L3 dinâmicas com túneis mGRE fornece um mecanismo de transporte L3 baseado em uma tecnologia avançada de tunelamento mGRE para uso em redes IP. O transporte dinâmico de tunelamento L3 também pode ser usado em redes IP para transportar tráfego VPN através de redes de provedores de serviços e corporativas, e para fornecer interoperabilidade para o transporte de pacotes entre VPNs IP e MPLS. Este recurso oferece suporte para RFC 2547, que define a terceirização de serviços de backbone IP para redes corporativas.
Aqui está uma lista de restrições que se aplicam a VPNs L3 dinâmicas com túneis mGRE:
Esta seção descreve duas configurações:
Essas são as configurações necessárias no Roteador 3 (R3) e no Roteador 2 (R2).
Aqui está a configuração para o R3:
l3vpn encapsulation ip MGRE
transport ipv4 source Loopback0
route-map MGRE-NEXT-HOP permit 10
set ip next-hop encapsulate l3vpn MGRE
router bgp 65534
!
address-family vpnv4
neighbor 192.168.2.2 route-map MGRE-NEXT-HOP in
Aqui está a configuração para o R2:
l3vpn encapsulation ip MGRE
transport ipv4 source Loopback0
route-map MGRE-NEXT-HOP permit 10
set ip next-hop encapsulate l3vpn MGRE
router bgp 65534
!
address-family vpnv4
neighbor 192.168.3.3 route-map MGRE-NEXT-HOP in
Use esta seção para confirmar se a sua configuração funciona corretamente.
R2#show tunnel endpoints
Tunnel0 running in multi-GRE/IP mode
Endpoint transport 192.168.3.3 Refcount 3 Base 0x1E8E1B74 Create Time 00:47:53
overlay 192.168.3.3 Refcount 2 Parent 0x1E8E1B74 Create Time 00:47:53
R2#show l3vpn encapsulation ip MGRE
Profile: MGRE
transport ipv4 source Loopback0
protocol gre
payload mpls
mtu default
Tunnel Tunnel0 Created [OK]
Tunnel Linestate [OK]
Tunnel Transport Source Loopback0 [OK]
R2#show ip route vrf MGRE 172.16.3.3
Routing Table: MGRE
Routing entry for 172.16.3.3
Known via "bgp 65534", distance 200, metric 0, type internal
Last update from 192.168.3.3 on Tunnel0, 01:03:25 ago
Routing Descriptor Blocks:
* 192.168.3.3 (default), from 172.16.112.1, 01:03:25 ago, via Tunnel0 <points to tunnel
Route metric is 0, traffic share count is 1
AS Hops 0
MPLS label: 17 <BGP vpnv4 label>
MPLS Flags: MPLS Required
Se você tiver um cenário de conexão dupla em que uma conexão é MPLS e a outra não é MPLS, você deve configurar o mGRE em todos os roteadores PE envolvidos. Com essa topologia, você deve configurar o mGRE nos três roteadores PE.
Se você não configurou mGRE na conexão entre o link R3 e R1 - MPLS, as sub-redes atrás de R3 não poderão se comunicar com as sub-redes atrás de R2.
Os pontos finais do túnel de construção R1 e R2 com R3 com base no perfil L3 VPN. Consulte a configuração neste documento onde o perfil L3 VPN não está configurado, o mapa de rota para o peer do Border Gateway Protocol (BGP) em R3 não é aplicado e o mapa de rota para a VPN L3 em R1 não é aplicado.
Essas são as configurações necessárias em R1, R2 e R3.
Aqui está a configuração para R1:
l3vpn encapsulation ip MGRE
transport ipv4 source Loopback0
route-map MGRE-NEXT-HOP permit 10
set ip next-hop encapsulate l3vpn MGRE
router bgp 65534
address-family vpnv4
neighbor 192.168.2.2 send-community extended
neighbor 192.168.2.2 route-map MGRE-NEXT-HOP in
neighbor 192.168.3.3 activate
Aqui está a configuração para o R2:
l3vpn encapsulation ip MGRE
transport ipv4 source Loopback0
route-map MGRE-NEXT-HOP permit 10
set ip next-hop encapsulate l3vpn MGRE
router bgp 65534
address-family vpnv4
neighbor 192.168.1.1 route-map MGRE-NEXT-HOP in
neighbor 192.168.1.1 activate
Aqui está a configuração para o R3:
router bgp 65534
address-family vpnv4
neighbor 192.168.1.1 activate
Agora, você pode fazer ping do loopback1 de R2 para o loopback1 de R3:
R2#ping vrf MGRE 172.16.3.3 source 172.16.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.3.3, timeout is 2 seconds:
Packet sent with a source address of 172.16.2.2
.....
Success rate is 0 percent (0/5)
R2#show ip route vrf MGRE 172.16.3.3
Routing Table: MGRE
Routing entry for 172.16.3.3/32
Known via "bgp 65534", distance 200, metric 0, type internal
Last update from 192.168.3.3 on Tunnel0, 00:50:23 ago
Routing Descriptor Blocks:
* 192.168.3.3 (default), from 192.168.1.1, 00:50:23 ago, via Tunnel0pointed towards a tunnel>
Route metric is 0, traffic share count is 1
AS Hops 0
MPLS label: 19
MPLS Flags: MPLS Required
R2#show tunnel endpoints
Tunnel1 running in multi-GRE/IP mode
Tunnel0 running in multi-GRE/IP mode
Endpoint transport 192.168.1.1 Refcount 3 Base 0x507665E4 Create Time 01:24:25
overlay 192.168.1.1 Refcount 2 Parent 0x507665E4 Create Time 01:24:25
Endpoint transport 192.168.3.3 Refcount 3 Base 0x507664D4 Create Time 00:50:51
overlay 192.168.3.3 Refcount 2 Parent 0x507664D4 Create Time 00:50:51
O R2 criou um túnel dinâmico para 192.168.3.3 com base no próximo salto BGP para a rota 172.16.3.3.
R2#show ip bgp vpnv4 vrf MGRE 172.16.3.3
BGP routing table entry for 43984:300:172.16.3.3/32, version 29
Paths: (1 available, best #1, table MGRE)
Advertised to update-groups:
1
Local, imported path from 300:300:172.16.3.3/32
192.168.3.3 (metric 3) (via Tunnel0) from 192.168.1.1 (192.168.1.1)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: RT:43984:300
Originator: 192.168.3.3, Cluster list: 192.168.1.1
mpls labels in/out nolabel/19
Ele é verificado em R1 e também criou terminais de túnel para ambos os roteadores PE:
R1#show tunnel endpoints
Tunnel1 running in multi-GRE/IP mode
Tunnel0 running in multi-GRE/IP mode
Endpoint transport 192.168.2.2 Refcount 3 Base 0x1E8EE7B0 Create Time 01:36:41
overlay 192.168.2.2 Refcount 2 Parent 0x1E8EE7B0 Create Time 01:36:41
Endpoint transport 192.168.3.3 Refcount 3 Base 0x1E8EE590 Create Time 00:59:34
overlay 192.168.3.3 Refcount 2 Parent 0x1E8EE590 Create Time 00:59:34
Em R3, nenhum endpoint de túnel é criado:
R3#show tunnel endpoints
Aqui está a rota para a sub-rede R2, que originou o ping:
R3#show ip route vrf MGRE 172.16.2.2
Routing Table: MGRE
Routing entry for 172.16.2.2/32
Known via "bgp 65534", distance 200, metric 0, type internal
Last update from 192.168.2.2 01:01:57 ago
Routing Descriptor Blocks:
* 192.168.2.2 (default), from 192.168.1.1, 01:01:57 ago
Route metric is 0, traffic share count is 1
AS Hops 0
MPLS label: 17
MPLS Flags: MPLS Required
Portanto, o pacote é enviado encapsulado em GRE para R3. Como R3 não tem túnel, ele não aceita o pacote GRE e o descarta.
Portanto, você deve configurar o mGRE fim-a-fim em um caminho para fazê-lo funcionar. Aqui está a configuração para mGRE em R3, que é necessária:
l3vpn encapsulation ip MGRE
transport ipv4 source Loopback0
route-map MGRE-NEXT-HOP permit 10
set ip next-hop encapsulate l3vpn MGRE
Assim que você cria o perfil L3 VPN, os pontos finais do túnel são criados e você recebe o tráfego que foi descartado anteriormente. No entanto, o tráfego de retorno é MPLS e não GRE até que você aplique o perfil no peer BGP. Esse tráfego é descartado em R1, porque R1 não tem nenhuma informação de rótulo para R2, que executa somente IP.
R3#show tunnel endpoints
Tunnel0 running in multi-GRE/IP mode
Endpoint transport 192.168.1.1 Refcount 3 Base 0x2B79FBD4 Create Time 00:00:02
overlay 192.168.1.1 Refcount 2 Parent 0x2B79FBD4 Create Time 00:00:02
Endpoint transport 192.168.2.2 Refcount 3 Base 0x2B79FAC4 Create Time 00:00:02
overlay 192.168.2.2 Refcount 2 Parent 0x2B79FAC4 Create Time 00:00:02
R3#show ip cef vrf MGRE 172.16.2.2
172.16.2.2/32
nexthop 192.168.13.1 GigabitEthernet0/0.1503 label 21 17
router bgp 65534
address-family vpnv4
neighbor 192.168.1.1 route-map MGRE-NEXT-HOP in
R3#show ip cef vrf MGRE 172.16.2.2
172.16.2.2/32
nexthop 192.168.2.2 Tunnel0 label 17
R2#ping vrf MGRE 172.16.3.3 source 172.16.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.3.3, timeout is 2 seconds:
Packet sent with a source address of 172.16.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
Cenário 3
Suponha que as sub-redes atrás de R5, que precisam se comunicar com R3, não queiram usar mGRE. Em seguida, você pode usar o mapa de rota usado para o perfil de VPN L3 para definir o próximo salto e chamar uma lista de prefixos e permitir apenas os prefixos que precisam do túnel mGRE.
Aqui está a configuração para R1:
route-map MGRE-NEXT-HOP permit 10
match ip address prefix-list test
set ip next-hop encapsulate l3vpn MGRE
route-map MGRE-NEXT-HOP permit 20
Você pode permitir prefixos no teste de lista de prefixos que precisam do túnel mGRE, e tudo o mais não tem um túnel como uma interface de saída e segue o roteamento normal. Essa configuração funciona porque R3 e R5 têm conectividade MPLS fim-a-fim.
Atualmente, não existem informações disponíveis específicas sobre Troubleshooting para esta configuração.
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
04-Nov-2013 |
Versão inicial |