13.14 Configuring the VRF for the VPN

Each VPN is required to have its own routing-instance . A routing instance is a section in the configuration hierarchy where the individual characteristics are assigned to the VPN. The VRF import and export policy to be used and the association of an interface to the VRF will be defined in the routing-instance . This procedure covers the necessary configuration steps to create the routing- instance to support each VPN.

 [edit]  lab@Chicago# edit routing-instances  instance name  

The following statement is used to name the routing-instance :

 [edit routing-instances  instance name  ]  lab@Chicago# set instance-type vrf 

The following statement defines the routing-instance as the VRF to be used for the VPN named VPN-Red:

 [edit routing-instances  instance name  ]  lab@Chicago# set interface  interface name  

The interface statement configured under the routing-instance should specify the interface that is physically connected to the CE router. However, when manipulating JUNOS, this is the logical interface, not the physical. In other words, it is necessary to include the logical unit number when performing this configuration.

 [edit routing-instances  instance name  ]  lab@Chicago# set route-distinguisher  rd type  

Note

The RD will be specified as mentioned earlier. The rd type value will be either a [16 bit:32 bit] or an [IP address:16 bit] value.

13.14.1 VPN Policy

The following policy-statements are used to determine which learned routes would be installed into the VRF on the PE router. Refer to Chapter 10 for more detailed explanations of general policy. The examples in this section are used strictly for VPNs.

 [edit]  lab@Chicago# edit policy-options policy-statement  policy name  [edit policy-options policy-statement  policy name  ] lab@Chicago# set term A from protocol bgp community  value  

Note

The entry for the value field should be the route target community used when the PE router distributes these routes to other PE routers.

 [edit policy-options policy-statement  policy name  ]  lab@Chicago# set term A then accept [edit policy-options policy-statement  policy name  ] lab@Chicago# set term B then reject 

The following statement will be used to associate the routing-instance VRF to the policy-statement . All routes that match that policy-statement will be imported into the VRF.

 [edit routing-instances VPN-Red]  lab@Chicago# set vrf-import MY-IMPORT 

The following statements define the export policy to be used to control which routes are distributed from the PE router to other PE routers in the network:

 [edit policy-options policy-statement  policy name  ]  lab@Chicago# set term A from protocol ospf 

Note

In this example, OSPF is the protocol used to exchange routes with the CE router. If using BGP or static routes, that option would be chosen instead of OSPF.

 [edit policy-options policy-statement  policy name  ]  lab@Chicago# set term A then community add  community name  

Note

The community string that is being added through this policy tells the PE router to add this community string to the routes that are being received from the CE router. These routes will be announced via MBGP to the other PE router. Their import policy should be configured to accept routes with the same community.

 [edit policy-options policy-statement  policy_statement  ]  lab@Chicago# set term A then accept [edit policy-options policy-statement  policy_statement  ] lab@Chicago# set term B then reject 

The following statement will be used to associate the policy-statement with the routing-instance VRF. All routes that match that policy-statement will be exported from the VRF. These are the routes that will be sent to other PE routers in the network.

 [edit routing-instances  instance name  ]  lab@Chicago# set vrf-export  instance name  

The following command defines the BGP extended route target community:

 [edit policy-options]  lab@Chicago# set community  community name  members target:  value