{"id":1213,"date":"2016-12-21T09:49:05","date_gmt":"2016-12-21T01:49:05","guid":{"rendered":"https:\/\/networkingnotesblog.wordpress.com\/?p=1213"},"modified":"2016-12-21T09:49:05","modified_gmt":"2016-12-21T01:49:05","slug":"mpls-vpn-routes-sharing-between-2-different-vrfs-across-the-mpls-network","status":"publish","type":"post","link":"http:\/\/notes4it.com\/?p=1213","title":{"rendered":"MPLS VPN – routes sharing between 2 different VRFs across the MPLS network"},"content":{"rendered":"

The beaut of MPLS VPN is to have multi tenants running over the same MPLS core network and each tenant are prevented to access other tenants networks. But what if the 2 different tenants want to connect to each other?
\nIn the lab below, we have 2 different tenants and they are 1120020010 (RT:200010) in Router 12 and 1030010010 (RT:100010) in Router 03. By default, the ASAs connected to these VRFs cannot communicate since they are in 2 different VRF network. In this case, I will be using Cisco IOS and Juniper MX to let 2 different VRFs to connect together.
\n\"20161221-mpls-2vrfs\"
\nWe could check the existing configuration and the route table in Router 03 and Router 12
\n
\nIn router 03, there are no 10.50.2.16\/30 nor 192.168.106.0\/25 in the VRF 1030010010 with the following configuration.<\/p>\n\n\n\n\n\n
set policy-options community 1030010010as5052 members target:5052:00100010<\/span><\/td>\n<\/tr>\n
set policy-options policy-statement 1030010010-export term 01-advertise from protocol direct
\nset policy-options policy-statement 1030010010-export term 01-advertise from protocol static
\nset policy-options policy-statement 1030010010-export term 01-advertise from protocol bgp
\nset policy-options policy-statement 1030010010-export term 01-advertise then community add 1030010010as5052
\nset policy-options policy-statement 1030010010-export term 01-advertise then accept
\nset policy-options policy-statement 1030010010-export term 99-reject then reject
\nset policy-options policy-statement 1030010010-import term 01-receive from protocol bgp
\nset policy-options policy-statement 1030010010-import term 01-receive from community 1030010010as5052
\nset policy-options policy-statement 1030010010-import term 01-receive then accept
\nset policy-options policy-statement 1030010010-import term 99-reject then reject<\/span><\/td>\n<\/tr>\n
set routing-instances 1030010010 instance-type vrf
\nset routing-instances 1030010010 interface ge-0\/0\/2.3979
\nset routing-instances 1030010010 route-distinguisher 5052:1030010010
\nset routing-instances 1030010010 vrf-import 1030010010-import
\nset routing-instances 1030010010 vrf-export 1030010010-export
\nset routing-instances 1030010010 vrf-table-label
\nset routing-instances 1030010010 routing-options static route 192.168.104.0\/24 next-hop 10.50.2.10<\/span>
\nset routing-instances 1030010010 routing-options router-id 10.50.2.9<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n\n\n
netuser@net-AS5052-vMX-R03> show route table 1030010010.inet.0<\/span><\/td>\n<\/tr>\n
1030010010.inet.0: 9 destinations, 15 routes (9 active, 0 holddown, 0 hidden)
\n+ = Active Route, – = Last Active, * = Both10.50.2.0\/31\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 *[BGP\/170] 2d 12:33:43, localpref 100, from 10.50.0.8
\nAS path: I, validation-state: unverified
\n> to 10.50.1.17 via ge-0\/0\/1.3992, Push 16, Push 422384(top)
\n[BGP\/170] 2d 12:33:43, localpref 100, from 10.50.0.9
\nAS path: I, validation-state: unverified
\n> to 10.50.1.17 via ge-0\/0\/1.3992, Push 16, Push 422384(top)
\n10.50.2.2\/31\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 *[BGP\/170] 2d 18:01:11, localpref 100, from 10.50.0.8
\nAS path: I, validation-state: unverified
\n> to 10.50.1.11 via ge-0\/0\/1.3995, Push 16
\n[BGP\/170] 2d 18:01:11, localpref 100, from 10.50.0.9
\nAS path: I, validation-state: unverified
\n> to 10.50.1.11 via ge-0\/0\/1.3995, Push 16
\n10.50.2.4\/31\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 *[BGP\/170] 2d 12:33:43, MED 0, localpref 100, from 10.50.0.8
\nAS path: ?, validation-state: unverified
\n> to 10.50.1.17 via ge-0\/0\/1.3992, Push 43, Push 463904(top)
\n[BGP\/170] 2d 12:33:43, MED 0, localpref 100, from 10.50.0.9
\nAS path: ?, validation-state: unverified
\n> to 10.50.1.17 via ge-0\/0\/1.3992, Push 43, Push 463904(top)
\n10.50.2.8\/29\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 *[Direct\/0] 6d 00:34:58
\n> via ge-0\/0\/2.3979
\n10.50.2.9\/32\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 *[Local\/0] 6d 00:34:58
\nLocal via ge-0\/0\/2.3979
\n192.168.104.0\/24\u00a0\u00a0 *[Static\/5] 6d 00:34:58
\n> to 10.50.2.10 via ge-0\/0\/2.3979
\n192.168.107.0\/25\u00a0\u00a0 *[BGP\/170] 2d 12:33:43, localpref 100, from 10.50.0.8
\nAS path: 65530 I, validation-state: unverified
\n> to 10.50.1.17 via ge-0\/0\/1.3992, Push 16, Push 422384(top)
\n[BGP\/170] 2d 12:33:43, localpref 100, from 10.50.0.9
\nAS path: 65530 I, validation-state: unverified
\n> to 10.50.1.17 via ge-0\/0\/1.3992, Push 16, Push 422384(top)
\n192.168.108.0\/24\u00a0\u00a0 *[BGP\/170] 2d 18:01:11, localpref 100, from 10.50.0.8
\nAS path: I, validation-state: unverified
\n> to 10.50.1.11 via ge-0\/0\/1.3995, Push 16
\n[BGP\/170] 2d 18:01:11, localpref 100, from 10.50.0.9
\nAS path: I, validation-state: unverified
\n> to 10.50.1.11 via ge-0\/0\/1.3995, Push 16
\n192.168.109.0\/24\u00a0\u00a0 *[BGP\/170] 2d 12:33:43, MED 0, localpref 100, from 10.50.0.8
\nAS path: ?, validation-state: unverified
\n> to 10.50.1.17 via ge-0\/0\/1.3992, Push 42, Push 463904(top)
\n[BGP\/170] 2d 12:33:43, MED 0, localpref 100, from 10.50.0.9
\nAS path: ?, validation-state: unverified
\n> to 10.50.1.17 via ge-0\/0\/1.3992, Push 42, Push 463904(top)<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n


\nIn router 12, there are no 10.50.2.8\/29 nor 192.168.104.0\/24 in the VRF 1120020010 with the following configuration.<\/p>\n\n\n\n\n
vrf definition 1120020010
\nrd 5052:1120020010
\nroute-target export 5052:200010
\nroute-target import 5052:200010
\n!
\naddress-family ipv4
\nexit-address-family
\n<\/span><\/td>\n<\/tr>\n
router bgp 5052
\n!
\naddress-family ipv4 vrf 1120020010
\nredistribute connected
\nneighbor 10.50.2.18 remote-as 65530
\nneighbor 10.50.2.18 activate
\nexit-address-family
\n!
\n<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n\n\n
net-AS5052-vIOS-R12#sho ip route vrf 1120020010
\n<\/span><\/td>\n<\/tr>\n
Routing Table: 1120020010
\nGateway of last resort is not set<\/span><\/span>10.0.0.0\/8 is variably subnetted, 2 subnets, 2 masks
\nC\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 10.50.2.16\/30 is directly connected, GigabitEthernet0\/2.3978
\nL\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 10.50.2.17\/32 is directly connected, GigabitEthernet0\/2.3978
\nB\u00a0\u00a0\u00a0\u00a0 192.168.101.0\/24 [200\/0] via 10.50.0.1, 20:01:19
\nB\u00a0\u00a0\u00a0\u00a0 192.168.103.0\/24 [200\/0] via 10.50.0.6, 20:01:19
\n192.168.106.0\/25 is subnetted, 1 subnets
\nB\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 192.168.106.0 [20\/0] via 10.50.2.18, 19:14:02<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n


\nSo how do we get to have both ASA from 2 different VRFs to talk together? One of the quick and dirty way is to have 1120020010 to take routes from RT:100010 and to have 1030010010 to take RT:200010 routes. (A better way is to create a new RT and have both VRF to take routers from the new RT. But the idea is to break the VPN barrier here.)<\/p>\n\n\n\n\n
We will add a new command to have the VRF at router 12 to put routes from RT:100010 into its routing table.<\/span><\/td>\n<\/tr>\n
vrf definition 1120020010
\nrd 5052:1120020010
\nroute-target export 5052:200010
\nroute-target import 5052:200010
\n\u00a0route-target import 5052:100010<\/span><\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n\n\n
net-AS5052-vIOS-R12#sho ip route vrf 1120020010<\/span><\/td>\n<\/tr>\n
Gateway of last resort is not set
\n10.0.0.0\/8 is variably subnetted, 6 subnets, 4 masks
\nB\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 10.50.2.0\/31 [200\/0] via 10.50.0.1, 00:06:40<\/span>
\nB\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 10.50.2.2\/31 [200\/0] via 10.50.0.6, 00:06:40<\/span>
\nB\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 10.50.2.4\/31 [200\/0] via 10.50.0.10, 00:06:40<\/span>
\nB\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 10.50.2.8\/29 [200\/0] via 10.50.0.3, 00:06:40<\/span>
\nC\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 10.50.2.16\/30 is directly connected, GigabitEthernet0\/2.3978
\nL\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 10.50.2.17\/32 is directly connected, GigabitEthernet0\/2.3978
\nB\u00a0\u00a0\u00a0\u00a0 192.168.101.0\/24 [200\/0] via 10.50.0.1, 20:17:16
\nB\u00a0\u00a0\u00a0\u00a0 192.168.103.0\/24 [200\/0] via 10.50.0.6, 20:17:16
\nB\u00a0\u00a0\u00a0\u00a0 192.168.104.0\/24 [200\/0] via 10.50.0.3, 00:06:40<\/span>
\n192.168.106.0\/25 is subnetted, 1 subnets
\nB\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 192.168.106.0 [20\/0] via 10.50.2.18, 19:29:59
\n192.168.107.0\/25 is subnetted, 1 subnets
\nB\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 192.168.107.0 [200\/0] via 10.50.0.1, 00:06:40<\/span>
\nB\u00a0\u00a0\u00a0\u00a0 192.168.108.0\/24 [200\/0] via 10.50.0.6, 00:06:40<\/span>
\nB\u00a0\u00a0\u00a0\u00a0 192.168.109.0\/24 [200\/0] via 10.50.0.10, 00:06:40<\/span><\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Now we get to have all<\/strong> the routes from VRF RT:100010 in the 1120020010 VRF.
\n
\nWhat about router 03? I will have the VRF 1030010010 to put all of the routes with RT:5052:200010 into its routing table. The newly imported routes are highlighted in red, and that both 192.168.106.0\/25 and 10.50.2.16\/30 are in the routing table.<\/p>\n\n\n\n\n
set policy-options community 1030020010as5052 members target:5052:00200010
\n<\/span><\/td>\n<\/tr>\n
set policy-options policy-statement 1030010010-import term 01-receive from protocol bgp
\nset policy-options policy-statement 1030010010-import term 01-receive from community 1030010010as5052
\nset policy-options policy-statement 1030010010-import term 01-receive from community 1030020010as5052
\nset policy-options policy-statement 1030010010-import term 01-receive then accept
\nset policy-options policy-statement 1030010010-import term 99-reject then reject<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n\n\n
netuser@net-AS5052-vMX-R03> show route table 1030010010.inet.0
\n<\/span><\/td>\n<\/tr>\n
1030010010.inet.0: 13 destinations, 23 routes (13 active, 0 holddown, 0 hidden)
\n+ = Active Route, – = Last Active, * = Both
\n10.50.2.0\/31\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 *[BGP\/170] 2d 13:37:39, localpref 100, from 10.50.0.8
\nAS path: I, validation-state: unverified
\n> to 10.50.1.17 via ge-0\/0\/1.3992, Push 16, Push 422384(top)
\n[BGP\/170] 2d 13:37:39, localpref 100, from 10.50.0.9
\nAS path: I, validation-state: unverified
\n> to 10.50.1.17 via ge-0\/0\/1.3992, Push 16, Push 422384(top)
\n10.50.2.2\/31\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 *[BGP\/170] 2d 19:05:07, localpref 100, from 10.50.0.8
\nAS path: I, validation-state: unverified
\n> to 10.50.1.11 via ge-0\/0\/1.3995, Push 16
\n[BGP\/170] 2d 19:05:07, localpref 100, from 10.50.0.9
\nAS path: I, validation-state: unverified
\n> to 10.50.1.11 via ge-0\/0\/1.3995, Push 16
\n10.50.2.4\/31\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 *[BGP\/170] 2d 13:37:39, MED 0, localpref 100, from 10.50.0.8
\nAS path: ?, validation-state: unverified
\n> to 10.50.1.17 via ge-0\/0\/1.3992, Push 43, Push 463904(top)
\n[BGP\/170] 2d 13:37:39, MED 0, localpref 100, from 10.50.0.9
\nAS path: ?, validation-state: unverified
\n> to 10.50.1.17 via ge-0\/0\/1.3992, Push 43, Push 463904(top)
\n10.50.2.8\/29\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 *[Direct\/0] 6d 01:38:54
\n> via ge-0\/0\/2.3979
\n10.50.2.9\/32\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 *[Local\/0] 6d 01:38:54
\nLocal via ge-0\/0\/2.3979
\n10.50.2.16\/30\u00a0\u00a0\u00a0\u00a0\u00a0 *[BGP\/170] 00:00:11, MED 0, localpref 100, from 10.50.0.8<\/span>
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 AS path: ?, validation-state: unverified<\/span>
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 > to 10.50.1.22 via ge-0\/0\/1.3986, Push 16<\/span>
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 [BGP\/170] 00:00:11, MED 0, localpref 100, from 10.50.0.9<\/span>
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 AS path: ?, validation-state: unverified<\/span>
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 > to 10.50.1.22 via ge-0\/0\/1.3986, Push 16<\/span>
\n192.168.101.0\/24\u00a0\u00a0 *[BGP\/170] 00:00:11, localpref 100, from 10.50.0.8<\/span>
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 AS path: I, validation-state: unverified<\/span>
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 > to 10.50.1.17 via ge-0\/0\/1.3992, Push 17, Push 422384(top)<\/span>
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 [BGP\/170] 00:00:11, localpref 100, from 10.50.0.9<\/span>
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 AS path: I, validation-state: unverified<\/span>
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 > to 10.50.1.17 via ge-0\/0\/1.3992, Push 17, Push 422384(top)<\/span>
\n192.168.103.0\/24\u00a0\u00a0 *[BGP\/170] 00:00:11, localpref 100, from 10.50.0.8<\/span>
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 AS path: I, validation-state: unverified<\/span>
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 > to 10.50.1.11 via ge-0\/0\/1.3995, Push 17<\/span>
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 [BGP\/170] 00:00:11, localpref 100, from 10.50.0.9<\/span>
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 AS path: I, validation-state: unverified<\/span>
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 > to 10.50.1.11 via ge-0\/0\/1.3995, Push 17<\/span>
\n192.168.104.0\/24\u00a0\u00a0 *[Static\/5] 6d 01:38:54
\n> to 10.50.2.10 via ge-0\/0\/2.3979
\n192.168.106.0\/25\u00a0\u00a0 *[BGP\/170] 00:00:11, MED 0, localpref 100, from 10.50.0.8<\/span>
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 AS path: 65530 ?, validation-state: unverified<\/span>
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 > to 10.50.1.22 via ge-0\/0\/1.3986, Push 41<\/span>
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 [BGP\/170] 00:00:11, MED 0, localpref 100, from 10.50.0.9<\/span>
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 AS path: 65530 ?, validation-state: unverified<\/span>
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 > to 10.50.1.22 via ge-0\/0\/1.3986, Push 41<\/span>
\n192.168.107.0\/25\u00a0\u00a0 *[BGP\/170] 2d 13:37:39, localpref 100, from 10.50.0.8
\nAS path: 65530 I, validation-state: unverified
\n> to 10.50.1.17 via ge-0\/0\/1.3992, Push 16, Push 422384(top)
\n[BGP\/170] 2d 13:37:39, localpref 100, from 10.50.0.9
\nAS path: 65530 I, validation-state: unverified
\n> to 10.50.1.17 via ge-0\/0\/1.3992, Push 16, Push 422384(top)
\n192.168.108.0\/24\u00a0\u00a0 *[BGP\/170] 2d 19:05:07, localpref 100, from 10.50.0.8
\nAS path: I, validation-state: unverified
\n> to 10.50.1.11 via ge-0\/0\/1.3995, Push 16
\n[BGP\/170] 2d 19:05:07, localpref 100, from 10.50.0.9
\nAS path: I, validation-state: unverified
\n> to 10.50.1.11 via ge-0\/0\/1.3995, Push 16
\n192.168.109.0\/24\u00a0\u00a0 *[BGP\/170] 2d 13:37:39, MED 0, localpref 100, from 10.50.0.8
\nAS path: ?, validation-state: unverified
\n> to 10.50.1.17 via ge-0\/0\/1.3992, Push 42, Push 463904(top)
\n[BGP\/170] 2d 13:37:39, MED 0, localpref 100, from 10.50.0.9
\nAS path: ?, validation-state: unverified
\n> to 10.50.1.17 via ge-0\/0\/1.3992, Push 42, Push 463904(top)
\n<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n


\n 
\nHere we come with the connection test.
\nWe will ping from both ASA first.<\/p>\n\n\n\n\n
net-AS5052-vASA-F16# ping 10.50.2.10
\nType escape sequence to abort.
\nSending 5, 100-byte ICMP Echos to 10.50.2.10, timeout is 2 seconds:
\n!!!!!
\nSuccess rate is 100 percent (5\/5), round-trip min\/avg\/max = 1\/4\/10 ms
\n<\/span><\/td>\n<\/tr>\n
net-vASA-AS5052-F14# ping 10.50.2.18
\nType escape sequence to abort.
\nSending 5, 100-byte ICMP Echos to 10.50.2.18, timeout is 2 seconds:
\n!!!!!
\nSuccess rate is 100 percent (5\/5), round-trip min\/avg\/max = 1\/2\/10 ms<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Next, we will have the host behind the ASA to ping each other.<\/p>\n\n\n\n\n
\"20161221-mpls-host_test02\"
\n<\/span><\/td>\n<\/tr>\n
\"20161221-mpls-host_test\"<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

 
\nSo at the end of the day, manipulating VRFs routes using RT (route target) can break the barrier and link 2 VRFs together. Although this is a quick and dirty way, an ideal way to create another RT and to add the RT into the routes that needs to be learned by another tenant s VRF for ease of management.<\/p>\n","protected":false},"excerpt":{"rendered":"

The beaut of MPLS VPN is to have multi tenants running over the same MPLS core network and each tenant are prevented to access other tenants networks. But what if the 2 different tenants want to connect to each other? In the lab below, we have 2 different tenants and they are 1120020010 (RT:200010) in […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[24,26,75,90,94,111,145,205,208],"class_list":["post-1213","post","type-post","status-publish","format-standard","hentry","category-networking","tag-c1000v-en","tag-cisco-en","tag-ios-en","tag-juniper-en","tag-junos-en","tag-mpls-en","tag-route-target-en","tag-vmx-en","tag-vrf-en"],"_links":{"self":[{"href":"http:\/\/notes4it.com\/index.php?rest_route=\/wp\/v2\/posts\/1213","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/notes4it.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/notes4it.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/notes4it.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/notes4it.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1213"}],"version-history":[{"count":0,"href":"http:\/\/notes4it.com\/index.php?rest_route=\/wp\/v2\/posts\/1213\/revisions"}],"wp:attachment":[{"href":"http:\/\/notes4it.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1213"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/notes4it.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1213"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/notes4it.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1213"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}