Tungsten Fabric solution guide Gateway MX

Keywords: VPN Mac network firewall

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:

  1. Logical tunnel
  2. 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.

  1. Due to some problems in Junos, it is not suitable for mplsodp.

  2. 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

Posted by georgee.b on Thu, 11 Jun 2020 19:49:44 -0700