Author: Tony Liu translator: TF Compilation Group
1 Overview
This guide describes how to use MX as a gateway to provide external or underlay connectivity for the overlay layer managed by Tungsten Fabric (the original version is contract, and its open source version has been renamed Tungsten Fabric, where the contracts appear in this article are replaced by Tungsten Fabric).
Depending on the performance requirements, the gateway can connect to a backbone or leaf.
2 Underlay/INET
2.1 eBGP
In a typical IP architecture, all leaves, spines and gateways use eBGP to establish underlay connections.
2.2 IBGP
For iBGP, it is recommended to use RR (routing reflector) to avoid full mesh peer-to-peer connections between all BGP nodes.
3 Overlay/VPN
3.1 loopback address
Loopback addresses are assigned and distributed on each MX. It is used to control the BGP peer of the node and the tunneling of the vRouter. The connection between the Tungsten Fabric and the loopback address is provided by underlay.
If a separate interface is used for the control plane and data plane, the address of the control interface will be used as the next hop when MX advertises routing. To solve this problem, the loopback interface should be used for both the control plane and the data plane.
set interfaces lo0 unit 0 family inet address 10.6.0.31/32
3.2 BGP
3.2.1 AS
Typically, a gateway has a globally unique ASN.
set routing-options autonomous-system 64031
3.2.2 EBGP AND IBGP
When Tungsten Fabric and gateway are in different AS, eBGP will be used.
set protocols bgp group vpn-contrail type external set protocols bgp group vpn-contrail multihop set protocols bgp group vpn-contrail local-address 10.6.0.31 set protocols bgp group vpn-contrail keep all set protocols bgp group vpn-contrail family inet-vpn unicast set protocols bgp group vpn-contrail family evpn signaling set protocols bgp group vpn-contrail family route-target set protocols bgp group vpn-contrail neighbor 10.6.11.1 peer-as 64512
iBGP is used when the Tungsten Fabric and gateway are in the same AS.
set protocols bgp group vpn-contrail type internal set protocols bgp group vpn-contrail local-address 10.6.0.31 set protocols bgp group vpn-contrail keep all set protocols bgp group vpn-contrail family inet-vpn unicast set protocols bgp group vpn-contrail family evpn signaling set protocols bgp group vpn-contrail family route-target set protocols bgp group vpn-contrail neighbor 10.6.11.1
When the gateway global ASN is different from the Tungsten Fabric ASN, you can use local as to enable iBGP.
set protocols bgp group vpn-contrail type internal set protocols bgp group vpn-contrail local-address 10.6.0.31 set protocols bgp group vpn-contrail local-as 64512 set protocols bgp group vpn-contrail keep all set protocols bgp group vpn-contrail family inet-vpn unicast set protocols bgp group vpn-contrail family evpn signaling set protocols bgp group vpn-contrail family route-target set protocols bgp group vpn-contrail neighbor 10.6.11.1 peer-as 64512
3.3 BGP Family
3.3.1 L3VPN
set protocols bgp group vpn-contrail family inet-vpn unicast
3.3.2 EVPN
set protocols bgp group vpn-contrail family evpn signaling
3.3.3 ROUTE TARGET
set protocols bgp group vpn-contrail family route-target
Family "route target" is used for optimization. When configuring on MX, MX will publish route target route if VRF import policy exists. MX also checks the route target routing table before publishing VPN-IPv4 routes to neighbors. If the route target in the route is not advertised by the neighbor, MX will not advertise the route.
If the interfaces on the control plane and data plane are separate, MX receives the route target route from the Tungsten Fabric control node. The next hop in RT routing is the control node address (on the control plane). MX attempts to resolve the next hop in the MPLS table (inet.3) on the data plane, but fails. In this way, RT routing will not take effect, but will be hidden. As a result, MX does not publish routes. In order to solve this problem, we can add static route in inet.3, so that the next hop control interface can be resolved. MX then applies RT routing and publishes the route. Tungsten Fabric does not have such a problem because it does not attempt to parse the next hop.
3.4 Tunnel
Tunnel service must be enabled. Here is an example.
set chassis fpc 0 pic 0 tunnel-services bandwidth 1g
3.4.1 mplsgre tunnel
For L3VPN, after BGP receives the INET-VPN route and places it in table bgp.l3vpn.0, it will find the MPLS path for the route. BGP attempts to resolve the route in table inet.3. If successful, a GRE tunnel is created and MPLS routes are added to inet.3. Otherwise, the route will be hidden in BGP. L3VPN. 0.
After enabling tunneling, the routing for destination networks will be added to inet.3. Here is an example.
set routing-options dynamic-tunnels contrail source-address 10.6.0.31set routing-options dynamic-tunnels contrail greset routing-options dynamic-tunnels contrail destination-networks 10.6.11.0/24 source-address is the loopback address.
This is an example of GRE tunnel routing in table inet.3.
10.6.11.4/32 (1 entry, 1 announced) *Tunnel Preference: 300 Next hop type: Router, Next hop index: 0 Address: 0xd7a9210 Next-hop reference count: 3 Next hop: via gr-0/0/0.32769, selected Session Id: 0x0 State: Local AS: 64031 Age: 10 Validation State: unverified Task: DYN_TUNNEL Announcement bits (2): 0-Resolve tree 1 1-Resolve_IGP_FRR task AS path: I
This is the dynamic tunnel database.
> show dynamic-tunnels database *- Signal Tunnels #- PFE-down Table: inet.3 Destination-network: 10.6.11.0/24 Tunnel to: 10.6.11.1/32 State: Up (expires in 00:06:58 seconds) Reference count: 0 Next-hop type: gre Source address: 10.6.0.31 Next hop: gr-0/0/10.32769 State: Up Tunnel to: 10.6.11.7/32 State: Up Reference count: 2 Next-hop type: gre Source address: 10.6.0.31 Next hop: gr-0/0/10.32770 State: Up
3.4.2 MPLSOUDP TUNNEL
UDP tunnel is more suitable for load balancing.
set routing-options dynamic-tunnels contrail source-address 10.6.0.31 set routing-options dynamic-tunnels contrail udp set routing-options dynamic-tunnels contrail destination-networks 10.6.11.0/24
This is an example of UDP tunnel routing in table inet.3.
10.6.11.4/32 (1 entry, 1 announced) *Tunnel Preference: 300 Next hop type: Tunnel Composite, Next hop index: 0 Address: 0xd7a87f0 Next-hop reference count: 2 Tunnel type: UDP, Reference count: 5, nhid: 0 Destination address: 10.6.11.4, Source address: 10.6.0.31 State: Local AS: 64031 Age: 24:46 Validation State: unverified Task: DYN_TUNNEL Announcement bits (2): 0-Resolve tree 1 1-Resolve_IGP_FRR task AS path: I
When a route is exported from VRF to Tungsten Fabric, a policy needs to be added to attach to the encapsulation attribute (community).
set policy-options policy-statement vrf-export-provider-1 term t1 then community add provider-1 set policy-options policy-statement vrf-export-provider-1 term t1 then community add encap-udp set policy-options policy-statement vrf-export-provider-1 term t1 then accept set policy-options community provider-1 members target:64512:101 set policy-options community encap-udp members encapsulation:64512:13
3.5 Routing Instance
3.5.1 VRF
The vrf type of RI is used to keep L3 routes.
set routing-instances provider-1 instance-type vrf set routing-instances provider-1 interface lo0.11 set routing-instances provider-1 route-distinguisher 64512:101 set routing-instances provider-1 vrf-target target:64512:101; set routing-instances provider-1 vrf-table-label
3.5.2 virtual switch
(omitted)
4 route import / export
4.1 workflow
4.1.1 IMPORT
- First, BGP establishes a peer-to-peer relationship with Tungsten Fabric. If there is no VRF
For RI and import policy, table bgp.l3vpn.0 will not be created, and BGP cannot receive any INET-VPN routes. - After creating VRF RI (VRF table label must be configured), you can use implicit policy (implicit
Policy) or explicit policy. - Configuring VRF target enables implicit policies that import routes with specific RT communities and export routes with additional specific RTS
The route of the community. - Configure "VRF import" and "VRF export" to specify an explicit policy in case any other action is required.
- Using any VRF RI and import policy, the table bgp.l3vpn.0 is created.
- According to the import policy, create a rip group VPN unicast for each RT.
vpn-unicast target:64512:101, Address: 0xd7a8e40 Address Family: l3vpn, Flags: 0x4, References: 0 Export RIB: l3vpn.0 Import RIB: bgp.l3vpn.0 Secondary Import RIB: provider-1.inet.0
- BGP attempts to resolve the route in table inet.3. If successful, assign GRE tunnel. Otherwise, the route will be hidden.
- BGP receives INET-VPN route (route target) matching import policy
community), and put it in table bgp.l3vpn.0. Routes are also converted to INET routes and placed in the VRF table, which is the secondary import RIB in the RIB group. Otherwise, the route will be discarded.
This is an example of INET-VPN routing in table bgp.l3vpn.0. It is advertised by BGP from Tungsten Fabric; route identifier 10.6.11.4:2 consists of IP address of vRouter and ID assigned by vRouter; it is published from Tungsten Fabric control node 10.6.11.1; next hop is advertised through dynamic GRE tunnel interface gr-0/0/0.32769; MPLS label is 25.
10.6.11.4:2:172.16.11.3/32 *[BGP/170] 00:03:11, MED 100, localpref 100, from 10.6.11.1 AS path: 64512 ?, validation-state: unverified > via gr-0/0/0.32769, Push 25
The route is converted to INET route and placed in VRF.
172.16.11.3/32 *[BGP/170] 02:35:37, MED 100, localpref 100, from 10.6.11.1 AS path: 64512 ?, validation-state: unverified > via gr-0/0/0.32769, Push 25
4.1.2 EXPORT
To export a route from VRF, according to the export policy, the route will be converted from INET to INET-VPN, put into table bgp.l3vpn.0, and then exported by BGP. MPLS tags will be assigned to INET-VPN routes in table mpls.0.
This is the loopback interface in VRF, as shown in table bgp.l3vpn.0.
64512:101:172.16.11.250/32 *[Direct/0] 00:43:14 > via lo0.11 The route is advertised with MPLS label 300624 showing by "show route advertising-protocol bgp 10.6.11.1 detail".
The route is published with MPLS label 300624, and details can be displayed through "show route Advertising Protocol BGP 10.6.11.1 detail".
* 64512:101:172.16.11.250/32 (1 entry, 1 announced) BGP group vpn-contrail type External Route Distinguisher: 64512:101 VPN Label: 300624 Nexthop: Self Flags: Nexthop Change AS path: [64031] I
MPLS tags are assigned in table mpls.0.
300624 *[VPN/170] 00:55:34 receive table provider-1.inet.0, Pop
4.2 implicit VRF import / export strategy
With VRF target, you can create implicit import and export policies.
set routing-instances provider-1 instance-type vrf set routing-instances provider-1 vrf-table-label set routing-instances provider-1 vrf-target target:64512:101;
Implicit import policy will import with community“ target:64540:100 ". As a result, the“ target:64540 The route of: 100 "is imported into this RI.
> show policy __vrf-import-5b4s37-166-internal__ Policy __vrf-import-5b4s37-166-internal__: Term unnamed: from community __vrf-community-5b4s37-166-common-internal__ [target:64540:100 ] then accept Term unnamed: then reject
Implicit export policy will export with community“ target:64540:100 ". As a result, routes are published to Tungsten Fabric and imported into the“ target:64540:100 "in the virtual network.
> show policy __vrf-export-5b4s37-166-internal__ Policy __vrf-export-5b4s37-166-internal__: Term unnamed: then community + __vrf-community-5b4s37-166-common-internal__ [target:64540:100 ] accept
4.3 explicit VRF import / export strategy
Policies can be explicitly defined as import and export routes. In this example, the with“ target:64540:91 "and“ target:64540 The route of: 92 "is imported into RI. Route usage in RI“ target:64540:91 "and“ target:64540:92 "is advertised and imported into two virtual networks.
set policy-options policy-statement provider-1-export term t1 then community add provider-1 set policy-options policy-statement provider-1-export term t1 then accept set policy-options policy-statement provider-1-import term t1 from community provider-1 set policy-options policy-statement provider-1-import term t1 from community ext-host set policy-options policy-statement provider-1-import term t1 then accept set policy-options community ext-host members target:64510:101 set policy-options community provider-1 members target:64512:101 set routing-instances provider-1 instance-type vrf set routing-instances provider-1 interface lo0.11 set routing-instances provider-1 route-distinguisher 64512:101 set routing-instances provider-1 vrf-table-label set routing-instances provider-1 vrf-import provider-1-import set routing-instances provider-1 vrf-export provider-1-export
5 External/Underlay connection
What I want to say here is——
- There is a route in the master RI to direct the inress traffic (from external/underlay to overlay) to the VRF RI.
- There are routes in VRF RI to direct egress traffic (from overlay to external/underlay) to master RI.
- Route may leak static.
There are two work options:
- Logical tunnel
- Rip group and static route with next table
See the following sections for details.
5.1 logic tunnel
Logical tunnel is used to connect the master route instance and VRF route instance. Depending on usage, this is optional. Due to bandwidth constraints, decisions must be made by examining requirements and tunnel bandwidth on specific hardware.
5.1.1 static
This is an example of using static routing on a logical tunnel.
set chassis fpc 0 pic 0 tunnel-services set interfaces lt-0/0/0 unit 100 encapsulation frame-relay set interfaces lt-0/0/0 unit 100 dlci 10 set interfaces lt-0/0/0 unit 100 peer-unit 200 set interfaces lt-0/0/0 unit 100 family inet set interfaces lt-0/0/0 unit 200 encapsulation frame-relay set interfaces lt-0/0/0 unit 200 dlci 10 set interfaces lt-0/0/0 unit 200 peer-unit 100 set interfaces lt-0/0/0 unit 200 family inet set routing-options static route 172.16.11.0/24 next-hop lt-0/0/0.100 set routing-instances provider-1 interface lt-0/0/0.200 set routing-instances provider-1 routing-options static route 0.0.0.0/0 next-hop lt-0/0/0.200
5.1.2 dynamic
Here is an example of using aggregate routing to configure BGP peers between VRF and master.
set chassis fpc 0 pic 0 tunnel-services set interfaces lt-0/0/0 unit 100 encapsulation frame-relay set interfaces lt-0/0/0 unit 100 dlci 10 set interfaces lt-0/0/0 unit 100 peer-unit 200 set interfaces lt-0/0/0 unit 100 family inet address 192.168.200.0/31 set interfaces lt-0/0/0 unit 200 encapsulation frame-relay set interfaces lt-0/0/0 unit 200 dlci 10 set interfaces lt-0/0/0 unit 200 peer-unit 100 set interfaces lt-0/0/0 unit 200 family inet address 192.168.200.1/31 set protocols bgp group vrf type internal set protocols bgp group vrf local-address 192.168.200.0 set protocols bgp group vrf keep all set protocols bgp group vrf family inet unicast set protocols bgp group vrf export provider-1-export set protocols bgp group vrf neighbor 192.168.200.1 set policy-options policy-statement provider-1-export term t1 then community add provider-1 set policy-options policy-statement provider-1-export term t1 then accept set policy-options policy-statement provider-1-aggregate-export term 1 from protocol aggregate set policy-options policy-statement provider-1-aggregate-export term 1 from route-filter 172.16.11.0/24 exact set policy-options policy-statement provider-1-aggregate-export term 1 then next-hop self set policy-options policy-statement provider-1-aggregate-export term 1 then accept set policy-options community provider-1 members target:64512:101 set routing-instances provider-1 instance-type vrf set routing-instances provider-1 interface lt-0/0/0.200 set routing-instances provider-1 route-distinguisher 64512:101 set routing-instances provider-1 vrf-import provider-1-import set routing-instances provider-1 vrf-export provider-1-export set routing-instances provider-1 routing-options aggregate route 172.16.11.0/24 set routing-instances provider-1 protocols bgp group master type internal set routing-instances provider-1 protocols bgp group master local-address 192.168.200.1 set routing-instances provider-1 protocols bgp group master keep all set routing-instances provider-1 protocols bgp group master family inet unicast set routing-instances provider-1 protocols bgp group master export provider-1-aggregate-export set routing-instances provider-1 protocols bgp group master neighbor 192.168.200.0
5.2 next table
The routing table can be specified as the next hop of the route. Conceptually, you can do the same with inet.0 and vrf.inet.0.
90aa13ec-7906-4de8-9333-d9f504574c44-image.png
The problem with this solution is that it will cause routing loops. For example, the flow of 172.16.11.9 is directed vrf.inet.0. If there is no specific route resolution, it will return to inet.0 through the default route. To avoid this routing loop, Junos does not allow this configuration.
Junos also does not allow the third table to be configured.
5.3 RIB group
The RIB group is usually used to leak routes between routing tables. Conceptually, you can create a RIB group to route INET from vrf.inet.0 to inet.0, and you can create another RIB group to import INET routes from inet.0 to vrf.inet.0.
set routing-options rib-groups provider-1-master import-rib provider-1.inet.0 set routing-options rib-groups provider-1-master import-rib inet.0 set routing-options rib-groups master-provider-1 import-rib inet.0 set routing-options rib-groups master-provider-1 import-rib provider-1.inet.0 set protocols bgp group corp type external set protocols bgp group corp family inet unicast rib-group master-provider-1 set protocols bgp group corp export direct set protocols bgp group corp neighbor 10.6.30.1 peer-as 64041 set routing-instances provider-1 instance-type vrf set routing-instances provider-1 route-distinguisher 64512:101 set routing-instances provider-1 vrf-import provider-1-import set routing-instances provider-1 vrf-export provider-1-export set routing-instances provider-1 vrf-table-label set routing-instances provider-1 routing-options auto-export family inet unicast rib-group provider-1-master
This configuration leaks routes from inet.0 to vpn.inet.0. But from another perspective, routes received from Tungsten Fabric do not vpn.inet.0 to inet.0 because of Junos design. These routes have been leaked from bgp.13vpn.0, so vpn.inet.0 is the secondary RIB for these routes. The route in the secondary RIB will not leak again.
5.4 RIB group and next table
5.4.1 INGRESS
For inress traffic, since Junos does not leak the overlay/32 route from VRF to master, there are two options.
Add a build (aggregate) route in VRF and use the rip group leak from vrf.inet.0 to inet.0.
set routing-options rib-groups provider-1-master import-rib provider-1.inet.0 set routing-options rib-groups provider-1-master import-rib inet.0 set routing-options rib-groups provider-1-master import-policy provider-1-master-import set routing-instances provider-1 instance-type vrf set routing-instances provider-1 route-distinguisher 64512:101 set routing-instances provider-1 vrf-target target:64512:101 set routing-instances provider-1 vrf-table-label set routing-instances provider-1 routing-options static route 0.0.0.0/0 next-table inet.0 set routing-instances provider-1 routing-options generate route 172.16.11.0/24 next-table provider-1.inet.0 set routing-instances provider-1 routing-options auto-export family inet unicast rib-group provider-1-master
Add a static route with the next table to the vrf.inet.0.
set routing-options static route 172.16.11.0/24 next-table provider-1.inet.0
Option 2 is recommended.
Note that the export policy needs to be updated for routing protocols to advertise such static routes.
5.4.2 EGRESS
For egress traffic, there are two options.
Add a static route with the next table to inet.0 in VRF.
set routing-instances provider-1 routing-options static route 0.0.0.0/0 next-table inet.0
The problem here is that if it is the default route as described above, it will cause a routing loop. For example, the inress traffic to 172.16.11.5/32 is vrf.int.0 does not exist, but it will loop between the master and VRF. Routing loops can be avoided by using specific routes, but this is not dynamic and cannot be extended.
The route received by the protocol in the master is leaked to VRF.
set protocols bgp group corp type external set protocols bgp group corp family inet unicast rib-group bgp-corp-provider-1 set protocols bgp group corp export direct set protocols bgp group corp neighbor 10.6.30.1 peer-as 64041 set routing-options rib-groups bgp-corp-provider-1 import-rib inet.0 set routing-options rib-groups bgp-corp-provider-1 import-rib provider-1.inet.0
Similarly, due to the limitations of Junos, routes leaked into VRF (secondary RIB) cannot be published to Tungsten Fabric. The solution is to add a default reject route.
set routing-instances provider-1 routing-options static route 0.0.0.0/0 reject
5.4.3 solutions
As a conclusion, here is the solution.
- Route from mater leak to VRF for egress traffic.
- Add a static route in the master to use for the inress traffic.
Appendix A.1 is the complete configuration.
Note that this does not apply to MPLSoUDP.
5.5 forward filter and next table
The solution is to use forwarding filter to guide the traffic of ingress to VRF RI, and static route with next table to guide the traffic of egress to master RI.
The solution has two problems.
-
Due to some problems in Junos, it is not suitable for mplsodp.
-
To publish routes externally, you must add routes to the gateway itself. Ingress traffic will arrive at the filter first, so static routing is only used for notification purposes and has no impact on traffic.
5.6 VRF to VRF
Appendix A.2 is an example configuration.
Please note that due to family route target, in Tungsten Fabric, for exposed VN, remote VRF RT must be configured to import RT. Otherwise, the gateway will not publish INET-VPN routes from remote VRF.
5.7 Community
The routes in Tungsten Fabric have the following communities.
- route target
- encapsulation
- mac-mobility
- 0x8004 (security group)
- 0x8071 (origin VN)
Depending on usage (such as routing to an external cluster or another Tungsten Fabric cluster), these communities may or may not need to be cleaned up.
The configuration in Appendix A.2 is an example of cleaning up the community.
6 multiple clusters
A single gateway can support multiple clusters, which should have different ASN s.
- Gateway configuration ASN.
- Clusters have different dedicated ASN s.
- iBGP in the control node of each cluster.
- eBGP between gateway and control node of each cluster.
- Multiple BGP groups can share the same interface connected to different neighbor groups.
- If each cluster is in a separate network, each cluster has a dynamic tunnel group.
- Each cluster should have a separate public address space. Since there is no address conflict, a VRF routing instance can be shared by multiple clusters, and all the public virtual networks in the cluster must have the same routing target
target). As a result, public routes from one cluster will leak to another.
appendix
A.1 RIB group and next table
set version 18.3R1.9 set chassis fpc 0 pic 0 tunnel-services set interfaces ge-0/0/0 mac 52:54:00:8c:f9:2b set interfaces ge-0/0/0 unit 0 family inet address 10.6.30.2/30 set interfaces ge-0/0/1 mac 52:54:00:c4:ee:41 set interfaces ge-0/0/1 unit 0 family inet address 10.6.20.1/30 set interfaces fxp0 unit 0 family inet address 10.6.8.31/24 set interfaces lo0 unit 0 family inet address 10.6.0.31/32 set interfaces lo0 unit 11 family inet address 172.16.11.250/32 set interfaces lo0 unit 12 family inet address 172.16.12.250/32 set routing-options interface-routes rib-group inet master-direct-vrf set routing-options static route 172.16.11.0/24 next-table provider-1.inet.0 set routing-options static route 172.16.12.0/24 next-table provider-2.inet.0 set routing-options rib-groups bgp-corp-vrf import-rib inet.0 set routing-options rib-groups bgp-corp-vrf import-rib provider-1.inet.0 set routing-options rib-groups bgp-corp-vrf import-rib provider-2.inet.0 set routing-options rib-groups master-direct-vrf import-rib inet.0 set routing-options rib-groups master-direct-vrf import-rib provider-1.inet.0 set routing-options rib-groups master-direct-vrf import-rib provider-2.inet.0 set routing-options rib-groups master-direct-vrf import-policy rib-import-master-vrf set routing-options route-distinguisher-id 10.6.0.31 set routing-options autonomous-system 64031 set routing-options dynamic-tunnels contrail source-address 10.6.0.31 set routing-options dynamic-tunnels contrail gre set routing-options dynamic-tunnels contrail destination-networks 10.6.11.0/24 set protocols bgp group corp type external set protocols bgp group corp family inet unicast rib-group bgp-corp-vrf set protocols bgp group corp export direct set protocols bgp group corp neighbor 10.6.30.1 peer-as 64041 set protocols bgp group fabric type external set protocols bgp group fabric family inet unicast set protocols bgp group fabric export direct set protocols bgp group fabric neighbor 10.6.20.2 peer-as 64011 set protocols bgp group vpn-contrail type external set protocols bgp group vpn-contrail multihop set protocols bgp group vpn-contrail local-address 10.6.0.31 set protocols bgp group vpn-contrail keep all set protocols bgp group vpn-contrail family inet-vpn unicast set protocols bgp group vpn-contrail family route-target set protocols bgp group vpn-contrail neighbor 10.6.11.1 peer-as 64512 set policy-options policy-statement direct term t1 from protocol direct set policy-options policy-statement direct term t1 from protocol aggregate set policy-options policy-statement direct term t1 then accept set policy-options policy-statement direct term t2 from protocol static set policy-options policy-statement direct term t2 from route-filter 172.16.11.0/24 exact set policy-options policy-statement direct term t2 then accept set policy-options policy-statement direct term t3 from protocol static set policy-options policy-statement direct term t3 from route-filter 172.16.12.0/24 exact set policy-options policy-statement direct term t3 then accept set policy-options policy-statement rib-import-master-vrf term t2 from protocol direct set policy-options policy-statement rib-import-master-vrf term t2 then accept set policy-options policy-statement rib-import-master-vrf term end then reject set policy-options policy-statement vrf-export-provider-1 term t1 then community add provider-1 set policy-options policy-statement vrf-export-provider-1 term t1 then accept set policy-options policy-statement vrf-export-provider-1 term end then reject set policy-options policy-statement vrf-export-provider-2 term t1 then community add provider-2 set policy-options policy-statement vrf-export-provider-2 term t1 then accept set policy-options policy-statement vrf-export-provider-2 term end then reject set policy-options policy-statement vrf-import-provider-1 term t1 from community provider-1 set policy-options policy-statement vrf-import-provider-1 term t1 from community ext-host set policy-options policy-statement vrf-import-provider-1 term t1 then accept set policy-options policy-statement vrf-import-provider-1 term end then reject set policy-options policy-statement vrf-import-provider-2 term t1 from community provider-2 set policy-options policy-statement vrf-import-provider-2 term t1 from community ext-host set policy-options policy-statement vrf-import-provider-2 term t1 then accept set policy-options policy-statement vrf-import-provider-2 term end then reject set policy-options community all-encaps members encapsulation:*:* set policy-options community all-origin-vns members 0x8071:*:* set policy-options community all-security-groups members 0x8004:*:* set policy-options community encap-udp members encapsulation:64512:13 set policy-options community ext-host members target:64510:101 set policy-options community provider-1 members target:64512:101 set policy-options community provider-2 members target:64512:102 set routing-instances provider-1 instance-type vrf set routing-instances provider-1 interface lo0.11 set routing-instances provider-1 route-distinguisher 64512:101 set routing-instances provider-1 vrf-import vrf-import-provider-1 set routing-instances provider-1 vrf-export vrf-export-provider-1 set routing-instances provider-1 vrf-table-label set routing-instances provider-1 routing-options static route 0.0.0.0/0 reject set routing-instances provider-2 instance-type vrf set routing-instances provider-2 interface lo0.12 set routing-instances provider-2 route-distinguisher 64512:102 set routing-instances provider-2 vrf-import vrf-import-provider-2 set routing-instances provider-2 vrf-export vrf-export-provider-2 set routing-instances provider-2 vrf-table-label set routing-instances provider-2 routing-options static route 0.0.0.0/0 reject
A.2 VRF to VRF
set version 18.3R1.9 set chassis fpc 0 pic 0 tunnel-services set interfaces ge-0/0/0 mac 52:54:00:8c:f9:2b set interfaces ge-0/0/0 unit 0 family inet address 10.6.30.2/30 set interfaces ge-0/0/1 mac 52:54:00:c4:ee:41 set interfaces ge-0/0/1 unit 0 family inet address 10.6.20.1/30 set interfaces fxp0 unit 0 family inet address 10.6.8.31/24 set interfaces lo0 unit 0 family inet address 10.6.0.31/32 set routing-options route-distinguisher-id 10.6.0.31 set routing-options autonomous-system 64031 set routing-options dynamic-tunnels contrail source-address 10.6.0.31 set routing-options dynamic-tunnels contrail gre set routing-options dynamic-tunnels contrail destination-networks 10.6.11.0/24 set routing-options dynamic-tunnels contrail destination-networks 10.6.0.0/16 set protocols bgp group corp type external set protocols bgp group corp family inet unicast set protocols bgp group corp export direct set protocols bgp group corp neighbor 10.6.30.1 peer-as 64041 set protocols bgp group fabric type external set protocols bgp group fabric family inet unicast set protocols bgp group fabric export direct set protocols bgp group fabric neighbor 10.6.20.2 peer-as 64011 set protocols bgp group vpn-contrail type external set protocols bgp group vpn-contrail multihop set protocols bgp group vpn-contrail local-address 10.6.0.31 set protocols bgp group vpn-contrail keep all set protocols bgp group vpn-contrail family inet-vpn unicast set protocols bgp group vpn-contrail family route-target set protocols bgp group vpn-contrail neighbor 10.6.11.1 peer-as 64512 set protocols bgp group vpn-external type external set protocols bgp group vpn-external multihop set protocols bgp group vpn-external local-address 10.6.0.31 set protocols bgp group vpn-external keep all set protocols bgp group vpn-external family inet-vpn unicast set protocols bgp group vpn-external family route-target set protocols bgp group vpn-external export vpn-external-export set protocols bgp group vpn-external neighbor 10.6.0.41 peer-as 64041 set policy-options policy-statement direct term t1 from protocol direct set policy-options policy-statement direct term t1 then accept set policy-options policy-statement provider-1-export term t1 then accept set policy-options policy-statement provider-1-import term t1 from community provider-1 set policy-options policy-statement provider-1-import term t1 from community ext-host set policy-options policy-statement provider-1-import term t1 then accept set policy-options policy-statement vpn-external-export term t1 from community provider-1 set policy-options policy-statement vpn-external-export term t1 then community add ext-host set policy-options policy-statement vpn-external-export term t1 then community delete all-encaps set policy-options policy-statement vpn-external-export term t1 then community delete all-security-groups set policy-options policy-statement vpn-external-export term t1 then community delete all-origin-vns set policy-options policy-statement vpn-external-export term t1 then accept set policy-options community all-encaps members encapsulation:*:* set policy-options community all-origin-vns members 0x8071:*:* set policy-options community all-security-groups members 0x8004:*:* set policy-options community ext-host members target:64510:101 set policy-options community provider-1 members target:64512:101 set firewall family inet filter to-vrf term 1 from destination-address 172.16.11.0/24 set firewall family inet filter to-vrf term 1 then routing-instance provider-1 set firewall family inet filter to-vrf term default then accept set routing-instances provider-1 instance-type vrf set routing-instances provider-1 route-distinguisher 64512:101 set routing-instances provider-1 vrf-import provider-1-import set routing-instances provider-1 vrf-export provider-1-export