IPv6 sobre MPLS: 6PE e 6VPE
Desde sua concepção, diversas frentes na comunidade de operadores de redes incentivam a migração para o IPv6. O fato de o protocolo resolver praticamente todos os problemas que enfrentamos com o IPv4 fez com que diversos mecanismos de transição fossem sugeridos com o intuito de acelerar esta migração. Uma das necessidades endereçadas é a interconexão de ilhas IPv6 através de uma infraestrutura MPLS utilizando IPv4 para construir os LSPs. Esta interconexão pode ser através da tabela global (6PE — RFC 4798) ou através de IPv6 VPNs (6VPE — RFC 4659). Vamos falar sobre cada um destes métodos individualmente.
6PE
O 6PE consiste em interconectar ilhas IPv6 através de um core MPLS utilizando BGP Labeled-Unicast (AFI=2/SAFI=4). Como o underlay (core) utiliza MPLS para o transporte de pacotes IPv6, necessitamos um LSP entre os PEs dual stack (que implementam tanto IPv4 quanto IPv6).
Entre os PE, estabelecemos uma sessão BGP ipv6 labeled-unicast para anunciarmos os prefixos IPv6. O next-hop é resolvido para o endereço do outro PE apontando para um determinado next-hop. Temos também um IGP + MPLS neste core para que possamos formar o nosso LSP. No entanto, este LSP vai utilizar IPv4 como controle e distribuição de labels — fazendo com que o next-hop dos prefixos IPv6 possuam o formato “::FFFF:X.X.X.X” , onde “X.X.X.X” corresponde ao endereço IPv4 associado ao LSP.
Cisco IOS:PE-2#sh bgp ipv6 u CAFE:100::/64
BGP routing table entry for CAFE:100::/64, version 8
Paths: (1 available, best #1, table default)
Flag: 0x100
Advertised to update-groups:
1
Refresh Epoch 1
65123, (aggregated by 65123 10.10.10.10)
::FFFF:1.1.1.1 (metric 20) from 1.1.1.1 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, atomic-aggregate, best
mpls labels in/out nolabel/2
rx pathid: 0, tx pathid: 0x0Juniper:
PE-1> show route table inet6.3inet6.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both::ffff:2.2.2.2/128 *[LDP/9] 00:14:36, metric 1
> to 10.0.0.1 via em1.0, Push 16PE-1> show route cafe:a00::/64 detailinet6.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
cafe:a00::/64 (1 entry, 1 announced)
*BGP Preference: 170/-101
Next hop type: Indirect
Address: 0x9334d90
Next-hop reference count: 3
Source: 2.2.2.2
Next hop type: Router, Next hop index: 575
Next hop: 10.0.0.1 via em1.0, selected
Label operation: Push 2, Push 16(top)
Label TTL action: prop-ttl, prop-ttl(top)
Protocol next hop: ::ffff:2.2.2.2
Push 2
Indirect next hop: 94c0000 131070
State: <Active Int Ext>
Local AS: 64512 Peer AS: 64512
Age: 12:31 Metric: 0 Metric2: 1
Task: BGP_64512.2.2.2.2+179
Announcement bits (3): 0-KRT 1-BGP_RT_Background 2-Resolve tree 3
AS path: 65123 I (Atomic) Aggregator: 65123 20.20.20.20
Accepted
Route Label: 2
Localpref: 100
Router ID: 2.2.2.2
No trace, podemos ver os labels associados ao prefixo IPv6 (distribuido via BGP-LU) e o label de transporte usando o LSP associado aquele next-hop.
CE-1#traceroute ipv6
Target IPv6 address: cafe:a00::1
Source address or interface: cafe:100::1
Tracing the route to CAFE:A00::11 * * *
2 ::FFFF:10.0.0.1 [MPLS: Labels 16/18 Exp 0] 4 msec 3 msec 3 msec
3 CAFE:1:: [MPLS: Label 18 Exp 0] 3 msec 32 msec 5 msec
4 CAFE:1::1 5 msec 4 msec 3 msecCE-2#traceroute ipv6
Target IPv6 address: cafe:100::1
Source address or interface: cafe:a00::1
Tracing the route to CAFE:100::11 CAFE:1:: 1 msec 1 msec 0 msec
2 ::FFFF:10.0.1.1 [MPLS: Labels 18/2 Exp 0] 3 msec 2 msec 1 msec
3 CAFE:: 1 msec 4 msec 3 msec
4 CAFE::1 4 msec 4 msec 3 msec
No juniper, vemos que o “inner” label possui o valor 2. Isso ocorre pois configuramos explicitamente a address family para utilizar IPv6 explicit null (aparentemente, esta é a única opção suportada); enquanto no cisco ios um label fora do range reservado foi alocado (ou seja, explicit null não foi habilitado para a address family).
6VPE
A diferença aqui é que o domínio IPv6 é restrito à um contexto, ou VPN (sim, uma L3VPN). Sendo assim, é possível facilmente implementar uma topologia hub-and-spoke e utilizar endereços privados.
Cada domínio (ou contexto, ou vpn) corresponde à uma VRF (ou routing-instance). Uma sessão vpnv6 (ou inet6-vpn — AFI=2/SAFI=128) é estabelecida, e os prefixos IPv6 são anunciados da mesma maneira como ocorre em uma L3VPN IPv4:
Cisco IOS:PE-2#sh bgp vpnv6 unicast vrf cust-65123 CAFE:100::/64
BGP routing table entry for [65123:65123]CAFE:100::/64, version 7
Paths: (1 available, best #1, table cust-65123)
Advertised to update-groups:
1
Refresh Epoch 1
65123, (aggregated by 65123 10.10.10.10)
::FFFF:1.1.1.1 (metric 20) (via default) from 1.1.1.1 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, atomic-aggregate, best
Extended Community: RT:65123:65123
mpls labels in/out nolabel/16
rx pathid: 0, tx pathid: 0x0Juniper:PE-1> show route receive-protocol bgp 2.2.2.2 detailcust-65123.inet6.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
* cafe:a00::/64 (1 entry, 1 announced)
Import Accepted
Route Distinguisher: 65123:65123
VPN Label: 16
Nexthop: ::ffff:2.2.2.2
MED: 0
Localpref: 100
AS path: 65123 I (Atomic) Aggregator: 65123 20.20.20.20
Communities: target:65123:65123bgp.l3vpn-inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)* 65123:65123:cafe:a00::/64 (1 entry, 0 announced)
Import Accepted
Route Distinguisher: 65123:65123
VPN Label: 16
Nexthop: ::ffff:2.2.2.2
MED: 0
Localpref: 100
AS path: 65123 I (Atomic) Aggregator: 65123 20.20.20.20
Communities: target:65123:65123
No exemplo também vemos a informação do next hop, bem similar ao que vemos no caso do 6PE. Comparando com o exemplo anterior, vemos que desta vez o Juniper alocou um label válido (fora do range reservado) para o prefixo — neste caso, não foi usado o IPv6 explicit null — e foi alocado um label para a vrf com o comando “vrf-table-label” .
Configuração
Para exemplificar o cenário, utilizaremos a seguinte topologia:
Nesta topologia temos duas redes IPv6 (AS 65123) que serão conectadas através de um LSP entre o PE1 e PE2 no AS 64512. No core (AS 64512) teremos um IGP e um protocolo de distribuição de labels qualquer.
No nosso lab, iremos configurar 6PE nos PE-1 e PE-2 para estabelecer conectividade IPv6 através do backbone MPLS composto pelos routers PE1–2 e P3. Neste backbone, não há roteamento IPv6, e faremos com que o tráfego IPv6 utilize o LSP construído entre as loopbacks dos PE-1 e PE-2. A config de IGP e MPLS não serão mostradas por brevidade.
Nos PE, habilitaremos uma sessão iBGP (IPv6 LU no 6PE / vpnv6 no 6VPE) com o outro PE, e também formaremos uma sessão eBGP com os CE:
PE-1set interfaces em2 unit 0 family inet6 address cafe::0/127set routing-options router-id 1.1.1.1
set routing-options autonomous-system 64512
set routing-options autonomous-system asdot-notationset protocols bgp group IBGP type internal
set protocols bgp group IBGP local-address 1.1.1.1
set protocols bgp group IBGP family inet unicast
set protocols bgp group IBGP family inet6 labeled-unicast explicit-null
set protocols bgp group IBGP export IBGP-OUT
set protocols bgp group IBGP neighbor 2.2.2.2set protocols bgp group AS-65123 advertise-peer-as
set protocols bgp group AS-65123 import AS-64512
set protocols bgp group AS-65123 family inet6 unicast
set protocols bgp group AS-65123 export AS-64512
set protocols bgp group AS-65123 peer-as 65123
set protocols bgp group AS-65123 neighbor cafe::1set policy-options policy-statement AS-65123 then accept
set policy-options policy-statement IBGP-OUT then next-hop selfPE-2ipv6 unicast-routingrouter bgp 64512
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 1.1.1.1 remote-as 64512
neighbor 1.1.1.1 update-source Loopback0
neighbor CAFE:1::1 remote-as 65123
!
address-family ipv6
neighbor 1.1.1.1 activate
neighbor 1.1.1.1 send-label
neighbor CAFE:1::1 activate
exit-address-family
Nos CE, nenhuma configuração adicional é necessária. os prefixos são recebidos através da AF IPv6 Unicast.
Finalizando a config, podemos ver o next-hop nos indicando o LSP com um endereço IPv4 mapeado para IPv6.
bersoare@PE-1> show route cafe:a00::/64 detailinet6.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
cafe:a00::/64 (1 entry, 1 announced)
*BGP Preference: 170/-101
Next hop type: Indirect
Address: 0x9334d90
Next-hop reference count: 3
Source: 2.2.2.2
Next hop type: Router, Next hop index: 575
Next hop: 10.0.0.1 via em1.0, selected
Label operation: Push 2, Push 16(top)
Label TTL action: prop-ttl, prop-ttl(top)
Protocol next hop: ::ffff:2.2.2.2
Push 2
Indirect next hop: 94c0000 131070
State: <Active Int Ext>
Local AS: 64512 Peer AS: 64512
Age: 12:31 Metric: 0 Metric2: 1
Task: BGP_64512.2.2.2.2+179
Announcement bits (3): 0-KRT 1-BGP_RT_Background 2-Resolve tree 3
AS path: 65123 I (Atomic) Aggregator: 65123 20.20.20.20
Accepted
Route Label: 2
Localpref: 100
Router ID: 2.2.2.2bersoare@PE-1> show route receive-protocol bgp 2.2.2.2 table inet6inet6.0: 8 destinations, 9 routes (8 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* cafe:a00::/64 ::ffff:2.2.2.2 0 100 65123 Ibersoare@PE-1> show route table inet6.3inet6.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both::ffff:2.2.2.2/128 *[LDP/9] 00:14:36, metric 1
> to 10.0.0.1 via em1.0, Push 16PE-2#sh ipv6 route
IPv6 Routing Table - default - 5 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, HA - Home Agent, MR - Mobile Router, R - RIP
H - NHRP, I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea
IS - ISIS summary, D - EIGRP, EX - EIGRP external, NM - NEMO
ND - ND Default, NDp - ND Prefix, DCE - Destination, NDr - Redirect
RL - RPL, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
la - LISP alt, lr - LISP site-registrations, ld - LISP dyn-eid
lA - LISP away, a - Application
C CAFE:1::/127 [0/0]
via Ethernet0/1, directly connected
L CAFE:1::/128 [0/0]
via Ethernet0/1, receive
B CAFE:100::/64 [200/0]
via 1.1.1.1%default, indirectly connected
B CAFE:A00::/64 [20/0]
via FE80::A8BB:CCFF:FE01:1000, Ethernet0/1
L FF00::/8 [0/0]
via Null0, receivePE-2#sh bgp ipv6 u labels
Network Next Hop In label/Out label
CAFE:100::/64 ::FFFF:1.1.1.1 nolabel/2
CAFE:A00::/64 CAFE:1::1 18/nolabelPE-2#sh bgp ipv6 u CAFE:100::/64
BGP routing table entry for CAFE:100::/64, version 8
Paths: (1 available, best #1, table default)
Flag: 0x100
Advertised to update-groups:
1
Refresh Epoch 1
65123, (aggregated by 65123 10.10.10.10)
::FFFF:1.1.1.1 (metric 20) from 1.1.1.1 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, atomic-aggregate, best
mpls labels in/out nolabel/2
rx pathid: 0, tx pathid: 0x0
Finalmente, nos CE podemos ver o caminho do traceroute. Nota-se os valores de label: um label associado a entrada IPv6 (distribuído via BGP) e o label de transporte (distribuído via IGP + LDP).
CE-1#traceroute ipv6
Target IPv6 address: cafe:a00::1
Source address or interface: cafe:100::1
Tracing the route to CAFE:A00::11 * * *
2 ::FFFF:10.0.0.1 [MPLS: Labels 16/18 Exp 0] 4 msec 3 msec 3 msec
3 CAFE:1:: [MPLS: Label 18 Exp 0] 3 msec 32 msec 5 msec
4 CAFE:1::1 5 msec 4 msec 3 msecCE-2#traceroute ipv6
Target IPv6 address: cafe:100::1
Source address or interface: cafe:a00::1
Tracing the route to CAFE:100::11 CAFE:1:: 1 msec 1 msec 0 msec
2 ::FFFF:10.0.1.1 [MPLS: Labels 18/2 Exp 0] 3 msec 2 msec 1 msec
3 CAFE:: 1 msec 4 msec 3 msec
4 CAFE::1 4 msec 4 msec 3 msec
Agora, vamos mudar esta config para utilizar o modelo vpn (6VPE). Basta alterar a configuração feita para o contexto de vrf e, no AS64512, configurar uma sessão IPv6 vpn unicast:
PE-1set routing-instances cust-65123 instance-type vrf
set routing-instances cust-65123 interface em2.0
set routing-instances cust-65123 route-distinguisher 65123:65123
set routing-instances cust-65123 vrf-target import target:65123:65123
set routing-instances cust-65123 vrf-target export target:65123:65123
set routing-instances cust-65123 vrf-table-label
set routing-instances cust-65123 protocols bgp group AS-65123 advertise-peer-as
set routing-instances cust-65123 protocols bgp group AS-65123 import AS-64512
set routing-instances cust-65123 protocols bgp group AS-65123 family inet6 unicast
set routing-instances cust-65123 protocols bgp group AS-65123 export AS-64512
set routing-instances cust-65123 protocols bgp group AS-65123 peer-as 65123
set routing-instances cust-65123 protocols bgp group AS-65123 neighbor cafe::1set protocols bgp group IBGP type internal
set protocols bgp group IBGP local-address 1.1.1.1
set protocols bgp group IBGP family inet unicast
set protocols bgp group IBGP family inet6-vpn unicast
set protocols bgp group IBGP export IBGP-OUT
set protocols bgp group IBGP neighbor 2.2.2.2set policy-options policy-statement AS-65123 then accept
set policy-options policy-statement IBGP-OUT then next-hop selfPE-2vrf definition cust-65123
rd 65123:65123
route-target export 65123:65123
route-target import 65123:65123
!
address-family ipv6
exit-address-family
!
router bgp 64512
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 1.1.1.1 remote-as 64512
neighbor 1.1.1.1 update-source Loopback0
!
address-family vpnv6
neighbor 1.1.1.1 activate
neighbor 1.1.1.1 send-community both
exit-address-family
!
address-family ipv6 vrf cust-65123
neighbor CAFE:1::1 remote-as 65123
neighbor CAFE:1::1 activate
exit-address-familyinterface Ethernet0/1
vrf forwarding cust-65123
no ip address
duplex auto
ipv6 address CAFE:1::/127
!
Agora vemos que a tabela de roteamento IPv6 esta associado com a vrf “cust-65123”, ao invés de estar na tabela global.
PE-1
bersoare@PE-1> show route table cust-65123cust-65123.inet6.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Bothcafe::/127 *[Direct/0] 01:32:41
> via em2.0
cafe::/128 *[Local/0] 01:32:41
Local via em2.0
cafe:100::/64 *[BGP/170] 01:32:22, MED 0, localpref 100
AS path: 65123 I
> to cafe::1 via em2.0
cafe:a00::/64 *[BGP/170] 01:32:08, MED 0, localpref 100, from 2.2.2.2
AS path: 65123 I
> to 10.0.0.1 via em1.0, Push 16, Push 16(top)
fe80::/64 *[Direct/0] 01:32:41
> via em2.0
fe80::5200:ff:fe01:2/128
*[Local/0] 01:32:41
Local via em2.0bersoare@PE-1> show route receive-protocol bgp 2.2.2.2 detailcust-65123.inet6.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
* cafe:a00::/64 (1 entry, 1 announced)
Import Accepted
Route Distinguisher: 65123:65123
VPN Label: 16
Nexthop: ::ffff:2.2.2.2
MED: 0
Localpref: 100
AS path: 65123 I (Atomic) Aggregator: 65123 20.20.20.20
Communities: target:65123:65123bgp.l3vpn-inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)* 65123:65123:cafe:a00::/64 (1 entry, 0 announced)
Import Accepted
Route Distinguisher: 65123:65123
VPN Label: 16
Nexthop: ::ffff:2.2.2.2
MED: 0
Localpref: 100
AS path: 65123 I (Atomic) Aggregator: 65123 20.20.20.20
Communities: target:65123:65123PE-2PE-2#show ipv6 cef vrf cust-65123 CAFE:100::/64 detail
CAFE:100::/64, epoch 0, flags [rib defined all labels]
recursive via 1.1.1.1 label 16
nexthop 10.0.1.1 Ethernet0/0 label 18-(local:20)PE-2#sh bgp vpnv6 unicast vrf cust-65123 CAFE:100::/64
BGP routing table entry for [65123:65123]CAFE:100::/64, version 7
Paths: (1 available, best #1, table cust-65123)
Advertised to update-groups:
1
Refresh Epoch 1
65123, (aggregated by 65123 10.10.10.10)
::FFFF:1.1.1.1 (metric 20) (via default) from 1.1.1.1 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, atomic-aggregate, best
Extended Community: RT:65123:65123
mpls labels in/out nolabel/16
rx pathid: 0, tx pathid: 0x0
PE-2#
PE-2#sh bgp vpnv6 unicast all labels
Network Next Hop In label/Out label
Route Distinguisher: 65123:65123 (cust-65123)
CAFE::/127 ::FFFF:1.1.1.1 nolabel/16
CAFE:100::/64 ::FFFF:1.1.1.1 nolabel/16
CAFE:A00::/64 CAFE:1::1 16/nolabel
Conclusão
Hoje falamos um pouco sobre 6PE e 6VPE, e como estas técnicas podem ser utilizadas para o estabelecimento de conectividade IPv6 sobre um backbone IPv4. Também demonstramos um exemplo de como configurar uma rede MPLS para tal transporte utilizando iBGP, tanto no modelo 6PE quanto no modelo 6VPE.
Se gostou do conteúdo, peço para compartilhar com outros do ramo. Não se esqueça de seguir a mim e ao TechRebels clicando follow aí embaixo :)
Sobre o autor:
Bernardo, CCIE #57862
Cloud Network Engineer
