lunedì 1 febbraio 2010

6VPE - ipv6 mpls VPN between cisco e junos

The spread of IPv6 in our networks is slow, but to refresh my IPv6 knowledge and use the LSPs configured in the previous post, I decided to configure an IPv6 mpls VPN between two sites.
This solution is called 6VPE and introduced on IOS a new configuration syntax for VRF.

Building the control plane

The operations are very similar to a IPv4 MPLS VPN: vpn prefix and label are signaled by mBGP while, LDP and/or RSVP ensure the label signaling necessary to forward MPLS packet throught the backbone.

The lab uses a virtual CE, realized exclusively with a loopback within each of the two PE involved. It thus avoids the entire PE-CE configuration as the purpose of the lab is to exercise on the MPLS component.

Peering mBGP

As vpnv6 signaling uses mBGP, we need to configure an iBGP peering between the two PE. The configuration proposed is minimal, and allows only the signaling of the vpnv6 AF (Address Family).

J2 Juniper PE

The BGP configuration necessarily require the use of a group (equivalent to a cisco peer-group) and the explicit peering type identification (internal vs. external). As previously mentioned only AF inet6-vpn unicast is enabled:
protocols {
    bgp {
        group iBGP {
            type internal;
            family inet6-vpn {
            neighbor {

routing-options {   
    autonomous-system 1;
In junos it is also mandatory to explicity enable the transport of IPv6 traffic over MPLS
[edit logical-systems J2]
nick@zion# show protocols | find mpls 
mpls {
    ipv6-tunneling;   /* enable ipv6 transport */
    label-switched-path J2-to-R6 {

R6 PE Cisco

The IOS PE requires a global enable for ipv6 ed ipv6 cef. In the BGP part is avoided the exchange of IPv4 prefixes while vpnv6 peering with a complete community exchange is enabled for J2.
ipv6 unicast-routing
ipv6 cef
router bgp 1
  no bgp default ipv4-unicast
  neighbor remote-as 1
  neighbor update-source Loopback0
address-family vpnv6
  neighbor activate
  neighbor send-community both

BGP session

It is always interesting to have a look at the communication capability negotiated BGP: The Open messages include the Multiprotocol Extension AFI (2) and SAFI (120) as indicated in the RFC:

Multiprotocol Extensions for BGP-4 rfc2858
Carrying Label Information in BGP-4 rfc3107
And as assigned by the IANA safi-namespace

The complete capture of BGP communication is here

VRF Configurations on Junos

Until now we have used the logical system of Junos isolating in its own stanza all the configuration statements for the virtual router realized.
The configuration of VRF rather intersects with the main routing instance ( or logical system ) which ensures the communication. The VRF is a particular routing-instance type in which the routing features are configured and the interfaced assigned, however the complete interface configuration remain global.

On J2 the IPv6 address fec0:cc1e:1::1/128 is configured on the new lo0 unit 102.

set logical-systems J2 interfaces lo0 unit 102 family inet6 address fec0:cc1e:1::1/128

then the "red" VRF routing instance is created, with route distinguisher assigned as the 2:2 route-target and 100:100.

set logical-systems J2 routing-instances red instance-type vrf
set logical-systems J2 routing-instances red route-distinguisher 2:2
set logical-systems J2 routing-instances red vrf-target target:100:100

Finally the newly configured unit 102 of the lo0 interface is associated with the routing-instance

set logical-systems J2 routing-instances red interface lo0.102

For those used to work with IOS there is no requirement to explicit configure the "redistribute connected" required to put the prefix in the mBGP table, all the prefix of the routing instance are automatically exported in mBGP.

this is the complete configuration in the usual form:
[edit logical-systems J2]
nick@zion# show interfaces lo0 
    unit 2 {
        family inet {
        family iso {
            address 49.0000.0000.0002.00;
    unit 102 {
        family inet6 {
            address fec0:cc1e:1::1/128;

[edit logical-systems J2]
nick@zion# show | find routing-instance 
routing-instances {
    red {
        instance-type vrf;
        interface lo0.102;
        route-distinguisher 2:2;
        vrf-target target:100:100;

The "vrf-table-label" is not required in this case, but serves to ensure the operation of MPLS VPN in Olive, where the forwarding is not PFE assisted.

VRF Definition on IOS

The 6VPE feature introduce a new configuration syntax and keywords with address-family, in this case RD 1:1 is used, while it is necessary to enable the redistribution of connected routes in the BGP process:

R6#sh run vrf red
Building configuration...

Current configuration : 354 bytes
vrf definition red
  rd 1:1
address-family ipv6
  route-target export 100:100
  route-target import 100:100
router bgp 1
address-family ipv6 vrf red
  redistribute connected metric 1
  no synchronization
interface Loopback106
  vrf forwarding red
  no ip address
  ipv6 address FEC0:CC1E:6::6/128

Check if everything works as expected

In Junos the routing-instance routing table, are prefixed with the istance name, then the remote prefix fec0:cc1e:6::6/128 are installed in the table named “red.inet6.0”

With a single command I can get all necessary label details:

Top Label = 16 - first hop Transport allocated with RSVP
Inner Label = 32 - VPN Label allocated by mBGP

nick@zion> show route logical-system J2 protocol bgp table red.inet6.0 detail

red.inet6.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
fec0:cc1e:6::6/128 (1 entry, 1 announced)
*BGP Preference: 170/-101
Route Distinguisher: 1:1
Next hop type: Indirect
Next-hop reference count: 3
Next hop type: Router, Next hop index: 885
Next hop: via fxp2.204 weight 0x1, selected
Label-switched-path J2-to-R6
Label operation: Push 32, Push 16(top)
Protocol next hop: ::ffff:
Push 32

Indirect next hop: 8d98330 131070
Local AS: 1 Peer AS: 1
Age: 27:26 Metric: 1 Metric2: 30
Task: BGP_1.
Announcement bits (1): 0-KRT
AS path: ?
Communities: target:100:100
Import Accepted
VPN Label: 32

Localpref: 100
Router ID:
Primary Routing Table bgp.l3vpn-inet6.0

On the IOS side it is necessary to use multiple commands to collect all the label information, sometimes with misleading results... however this is mainly due to the fact that we only use RSVP and the usually Cisco proposed solutions involve LDP:

R6#sh bgp vpnv6 unicast vrf red FEC0:CC1E:1::1/128
BGP routing table entry for [1:1]FEC0:CC1E:1::1/128, version 11
Paths: (1 available, best #1, table red)
Not advertised to any peer
Local, imported path from [2:2]FEC0:CC1E:1::1/128
::FFFF: (metric 30) from (
Origin IGP, localpref 100, valid, internal, best
Extended Community: RT:100:100
mpls labels in/out nolabel/16

R6#sh ipv6 cef vrf red FEC0:CC1E:1::1/128 detail
FEC0:CC1E:1::1/128, epoch 0
recursive via label 16
nexthop Tunnel0

R6#sh mpls traffic-eng tunnels tunnel 0 | i Label
InLabel : -
OutLabel : FastEthernet0/0, 299776

The powerful cef “hidden” IOS command

In IOS there is a hidden IOS command “show ipv6 cef internal” used to show a set information very useful for troubleshooting and to understand the solution mechanisms.

R6#show ipv6 cef vrf red internal | b FEC0:CC1E:1::1/128
FEC0:CC1E:1::1/128, epoch 0, RIB[B], refcount 3, per-destination sharing
sources: RIB
feature space:
LFD: FEC0:CC1E:1::1/128 0 local labels
contains path extension list
label switch chain 0x66BA9888
IPRM: 0x00018000
ifnums: (none)
path 659EAE98, path list 659E05F0, share 1/1, type recursive, for IPv6, flags must-be-labelled
MPLS short path extensions: MOI flags = 0x4 label 16
recursive via[IPv4:Default] label 16, fib 65A2F590, 1 terminal fib
path 659EAF0C, path list 659E063C, share 1/1, type attached nexthop, for IPv4
MPLS short path extensions: MOI flags = 0x1 label implicit-null
nexthop Tunnel0, adjacency IP midchain out of Tunnel0 65EF2C60
output chain: label 16 label implicit-null TAG midchain out of Tunnel0 65EF2AE0 label 299792 TAG adj out of FastEthernet0/0, addr 65EF2DE0

IPv4 to IPv6 Mappeed address

In the both cases there is a odd NEXT-HOP address indicated as ::FFFF: or ::FFFF: This is due to fact that the next-hop address required in the AFI/SAFI ipv6 is still an ipv6 address. In our case this is an IPv4 address ( the PE Loopback ) and this is replaced with IPv4 mapped IPv6 addess.

And in the end the ping...
This waste of energy to run a ping ... hope at least it works:
nick@zion> ping logical-system J2 routing-instance red fec0:cc1e:6::6
PING6(56=40+8+8 bytes) fec0:cc1e:1::1 --> fec0:cc1e:6::6
16 bytes from fec0:cc1e:6::6, icmp_seq=0 hlim=64 time=16.438 ms
16 bytes from fec0:cc1e:6::6, icmp_seq=1 hlim=64 time=17.256 ms
16 bytes from fec0:cc1e:6::6, icmp_seq=2 hlim=64 time=11.247 ms
16 bytes from fec0:cc1e:6::6, icmp_seq=3 hlim=64 time=11.361 ms
--- fec0:cc1e:6::6 ping6 statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 11.247/14.076/17.256/2.787 ms
on the cisco side:
R6#ping vrf red ipv6 fec0:cc1e:1::1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FEC0:CC1E:1::1, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/12/20 ms


MPLS and BGP are confirmed two key tools in providing simple and efficient solutions, allowing the transport of any type of traffic without changes to the backbone infrastructure.

BGP session capture here
Final Juniper configuration here
Final R4 configuration here
Final R6 Configuration here

Nessun commento:

Posta un commento