Hub-and-Spoke VPNs
Configuring Hub-and-Spoke VPN Topologies: One Interface
Use a one-interface configuration to advertise a default route from a hub or hubs.
Figure 1 illustrates a Layer 3 VPN hub-and-spoke application where there is only one interface between the hub CE (CE1) and the hub PE (PE1). This is the recommended way of configuring hub-and-spoke topologies.
In this configuration, a default route is advertised from the hub to the spokes. If more specific spoke CE routes need to be exchanged between spoke CE routers, then two interfaces are needed between the hub CE and hub PE. See Configuring Hub-and-Spoke VPN Topologies: Two Interfaces for a two-interface example.
In this configuration example, spoke route distribution is as follows:
Spoke CE2 advertises its routes to spoke PE2.
Spoke PE2 installs routes from CE2 into its VPN routing and forwarding (VRF) table.
Spoke PE2 checks its VRF export policy, adds the route target community, and announces the routes to hub PE1.
Hub PE1 checks its VRF import policy and installs routes that match the import policy into table bgp.l3vpn.0.
Hub PE1 installs routes from table bgp.l3vpn.0 into the hub VRF table.
Hub PE1 announces routes from the hub VRF table to the hub CE1.
In this configuration example, default route distribution is as follows:
Hub CE1 announces a default route to hub PE1.
Hub PE1 installs the default route into the hub VRF table.
Hub PE1 checks its VRF export policy, adds the route target community and announces the default route to spoke PE2 and PE3.
Spoke PE2 and PE3 check their VRF import policy and install the default route into table bgp.l3vpn.0.
Spoke PE2 and PE3 install the routes from table bgp.l3vpn.0 into their spoke VRF tables.
Spoke PE2 and PE3 announce the default route from the spoke VRF table to spoke CE2 and CE3.
The following sections describe how to configure a hub-and-spoke topology with one interface based on the topology illustrated in Figure 1:
- Configuring Hub CE1
- Configuring Hub PE1
- Configuring the P Router
- Configuring Spoke PE2
- Configuring Spoke PE3
- Configuring Spoke CE2
- Configuring Spoke CE3
- Enabling Egress Features on the Hub PE Router
Configuring Hub CE1
Configure hub CE1 as follows:
[edit routing-options]
static {
route 0.0.0.0/0 discard;
}
autonomous-system 100;
[edit protocols]
bgp {
group hub {
type external;
export default;
peer-as 200;
neighbor 10.49.4.1;
}
}
[edit policy-options]
policy-statement default {
term 1 {
from {
protocol static;
route-filter 0.0.0.0/0 exact;
}
then accept;
}
term 2 {
then reject;
}
}
Configuring Hub PE1
Configure hub PE1 as follows:
[edit]
routing-instances {
hub {
instance-type vrf;
interface t3-0/0/0;
route-distinguisher 10.255.14.176:2;
vrf-target {
import target:200:100;
export target:200:101;
}
protocols {
bgp {
group hub {
type external;
peer-as 100;
as-override;
neighbor 10.49.4.2;
}
}
}
}
}
Configuring the P Router
Configure the P Router as follows:
[edit]
interfaces {
t3-0/1/1 {
unit 0 {
family inet {
address 10.49.2.1/30;
}
family mpls;
}
}
t3-0/1/3 {
unit 0 {
family inet {
address 10.49.0.2/30;
}
family mpls;
}
}
t1-0/2/0 {
unit 0 {
family inet {
address 10.49.1.2/30;
}
family mpls;
}
}
}
[edit]
protocols {
ospf {
area 0.0.0.0 {
interface t3-0/1/3.0;
interface t1-0/2/0.0;
interface t3-0/1/1.0;
interface lo0.0 {
passive;
}
}
}
ldp {
interface t3-0/1/1.0;
interface t3-0/1/3.0;
interface t1-0/2/0.0;
}
}
Configuring Spoke PE2
Configure spoke PE2 as follows:
[edit]
interfaces {
t3-0/0/0 {
unit 0 {
family inet {
address 10.49.0.1/30;
}
family mpls;
}
}
t1-0/1/2 {
unit 0 {
family inet {
address 10.49.3.1/30;
}
}
}
}
[edit protocols]
bgp {
group ibgp {
type internal;
local-address 10.255.14.182;
peer-as 200;
neighbor 10.255.14.176 {
family inet-vpn {
unicast;
}
}
}
}
ospf {
area 0.0.0.0 {
interface t3-0/0/0.0;
interface lo0.0 {
passive;
}
}
}
ldp {
interface t3-0/0/0.0;
}
[edit]
routing-instances {
spoke {
instance-type vrf;
interface t1-0/1/2.0;
route-distinguisher 10.255.14.182:20;
vrf-target {
import target:200:101;
export target:200:100;
}
protocols {
bgp {
group spoke {
type external;
peer-as 100;
as-override;
neighbor 10.49.3.2;
}
}
}
}
}
Configuring Spoke PE3
Configure spoke PE3 as follows:
[edit]
interfaces {
t3-0/0/0 {
unit 0 {
family inet {
address 10.49.6.1/30;
}
}
}
t3-0/0/1 {
unit 0 {
family inet {
address 10.49.2.2/30;
}
family mpls;
}
}
}
[edit protocols}
bgp {
group ibgp {
type internal;
local-address 10.255.14.178;
peer-as 200;
neighbor 10.255.14.176 {
family inet-vpn {
unicast;
}
}
}
}
ospf {
area 0.0.0.0 {
interface t3-0/0/1.0;
interface lo0.0 {
passive;
}
}
}
ldp {
interface t3-0/0/1.0;
}
[edit]
routing-instances {
spoke {
instance-type vrf;
interface t3-0/0/0.0;
route-distinguisher 10.255.14.178:30;
vrf-target {
import target:200:101;
export target:200:100;
}
protocols {
bgp {
group spoke {
type external;
peer-as 100;
as-override;
neighbor 10.49.6.2;
}
}
}
}
}
Configuring Spoke CE2
Configure spoke CE2 as follows:
[edit routing-options]
autonomous-system 100;
{edit protocols]
bgp {
group spoke {
type external;
export loopback;
peer-as 200;
neighbor 10.49.3.1;
}
}
Configuring Spoke CE3
Configure spoke CE3 as follows:
[edit routing-options]
autonomous-system 100;
[edit protocols]
bgp {
group spoke {
type external;
export loopback;
peer-as 200;
neighbor 10.49.6.1;
}
}
In this configuration example, traffic forwarding is as follows between spoke CE2 and hub CE1:
Spoke CE2 forwards traffic using the default route learned from spoke PE2 through BGP.
0.0.0.0/0 *[BGP/170] 02:24:15, localpref 100 AS path: 200 200 I > to 10.49.3.1 via t1-3/0/1.0-
Spoke PE2 performs a route lookup in the spoke VRF table and forwards the traffic to hub PE1 (through the P router—PE2 pushes two labels) using the default route learned through BGP.
0.0.0.0/0 *[BGP/170] 01:35:45, localpref 100, from 10.255.14.176 AS path: 100 I > via t3-0/0/1.0, Push 100336, Push 100224(top) Hub PE1 does a route lookup in the mpls.0 table for the VPN label
100336.100336 *[VPN/170] 01:37:03 > to 10.49.4.2 via t3-0/0/0.0, PopHub PE1 forwards the traffic out the interface
t3-0/0/0.0to hub CE1.
In this configuration example, traffic forwarding is as follows between hub CE1 and spoke CE2:
Hub CE1 forwards traffic to the hub PE1 using the route learned through BGP.
10.49.10.250/32 *[BGP/170] 02:28:46, localpref 100 AS path: 200 200 I > to 10.49.4.1 via t3-3/1/0.0Hub PE1 does a route lookup in the hub VRF table and forwards the traffic to spoke PE2 (through the P router—PE1 pushes two labels).
10.49.10.250/32 *[BGP/170] 01:41:05, localpref 100, from 10.255.14.182 AS path: 100 I > via t1-0/1/0.0, Push 100352, Push 100208(top)Spoke PE2 does a route lookup in the mpls.0 table for the VPN label
100352.100352 *[VPN/170] 02:31:39 > to 10.49.3.2 via t1-0/1/2.0, PopSpoke PE2 forwards the traffic out the interface
t1-0/1/2.0to spoke CE2.
In this configuration example, traffic forwarding is as follows between spoke CE2 and spoke CE3:
Spoke CE2 forwards traffic using the default route learned from spoke PE2 through BGP.
0.0.0.0/0 *[BGP/170] 02:24:15, localpref 100 AS path: 200 200 I > to 10.49.3.1 via t1-3/0/1.0Spoke PE2 does a route lookup in the spoke VRF table and forwards the traffic to hub PE1 (through the P router—PE2 pushes two labels) using the default route learned through BGP.
0.0.0.0/0 *[BGP/170] 01:35:45, localpref 100, from 10.255.14.176 AS path: 100 I > via t3-0/0/1.0, Push 100336, Push 100224(top)Hub PE1 does a route lookup in the mpls.0 table for the VPN label
100336.100336 *[VPN/170] 01:37:03 > to 10.49.4.2 via t3-0/0/0.0, PopHub PE1 forwards the traffic out the interface
t3-0/0/0.0to the hub CE1.Hub CE1 forwards the traffic to hub PE1 using the router learned through BGP.
10.49.10.253/32 *[BGP/170] 02:40:03, localpref 100 AS path: 200 200 I > to 10.49.4.1 via t3-3/1/0.0Hub PE1 does a route lookup in the hub VRF table and forwards the traffic to spoke PE3 (through the P router—PE1 pushes two labels).
10.49.10.253/32 *[BGP/170] 01:41:05, localpref 100, from 10.255.14.178 AS path: 100 I > via t1-0/1/0.0, Push 100128, Push 100192(top)Spoke PE3 does a route lookup in the mpls.0 table for VPN label
100128.100128 *[VPN/170] 02:41:30 > to 10.49.6.2 via t3-0/0/0.0, PopSpoke PE3 forwards the traffic out the interface
t3-0/0/0.0to spoke CE3.
If egress features are needed on the hub PE that require an IP forwarding lookup on the hub VRF routing table, see Enabling Egress Features on the Hub PE Router.
Enabling Egress Features on the Hub PE Router
This example is provided in conjunction with Configuring Hub-and-Spoke VPN Topologies: One Interface. This example also uses the topology illustrated in Figure 1.
If egress features are needed on the hub PE that require an
IP forwarding lookup on the hub VRF routing table, the configuration
detailed in Configuring Hub-and-Spoke VPN Topologies: One Interface will not work.
Applying the vrf-table-label statement on the hub routing
instance forces traffic from a remote spoke PE to be forwarded to
the hub PE and forces an IP lookup to be performed. Because specific
spoke routes are in the hub VRF table, traffic will be forwarded to
a spoke PE without going through the hub CE.
The hub PE advertises the default route as follows, using VPN label 1028:
hub.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
* 0.0.0.0/0 (1 entry, 1 announced)
BGP group ibgp type Internal
Route Distinguisher: 10.255.14.176:2
VPN Label: 1028
Nexthop: Self
Localpref: 100
AS path: 100 I
Communities: target:200:101Incoming traffic is forwarded using VPN label 1028. The mpls.0 table shows that an IP lookup in the table hub.inet.0 is required:
1028 *[VPN/0] 00:00:27
to table hub.inet.0, PopHowever, the hub VRF table hub.inet.0 contains specific spoke routes:
10.49.10.250/32 *[BGP/170] 00:00:05, localpref 100, from 10.255.14.182
AS path: 100 I
> via t1-0/1/0.0, Push 100352, Push 100208(top)
10.49.10.253/32 *[BGP/170] 00:00:05, localpref 100, from 10.255.14.178
AS path: 100 I
> via t1-0/1/0.0, Push 100128, Push 100192(top)Because of this, traffic is forwarded directly to the spoke PEs without going through the hub CE. To prevent this, you must configure a secondary routing instance for downstream traffic in the hub PE1.
Configuring Hub PE1
Configure hub PE1 as follows:
[edit]
routing-instances {
hub {
instance-type vrf;
interface t3-0/0/0.0;
route-distinguisher 10.255.14.176:2;
vrf-target {
import target:200:100;
export target:200:101;
}
no-vrf-advertise;
routing-options {
auto-export;
}
protocols {
bgp {
group hub {
type external;
peer-as 100;
as-override;
neighbor 10.49.4.2;
}
}
}
}
hub-downstream {
instance-type vrf;
route-guisher 10.255.14.176:3;
vrf-target target:200:101;
vrf-table-label;
routing-options {
auto-export;
}
}
}
When the no-vrf-advertise statement is used at the [edit routing-instances hub] hierarchy level, no routing table
groups or VRF export policies are required. The no-vrf-advertise statement configures the hub PE not to advertise VPN routes from
the primary routing-instance hub. These routes are instead
advertised from the secondary routing instance hub_downstream. See Junos OS Routing Protocols Library for more information about the no-vrf-advertise statement.
The auto-export statement at the [edit routing-instances
hub-downstream routing-options] hierarchy level identifies routes
exported from the hub instance to the hub-downstream instance by looking
at the route targets defined for each routing instance. See Junos OS Routing Protocols Library for
more information about using the auto-export statement.
See Configuring Overlapping VPNs Using Automatic Route
Export for more examples of export policy.
With this configuration on hub PE, spoke-to-spoke CE traffic goes through the hub CE and permits egress features (such as filtering) to be enabled on the hub PE.
In this configuration example, traffic forwarding is as follows between spoke CE2 and spoke CE3:
Spoke CE2 forwards traffic using the default route learned from spoke PE2 through BGP.
0.0.0.0/0 *[BGP/170] 02:24:15, localpref 100 AS path: 200 200 I > to 10.49.3.1 via t1-3/0/1.0Spoke PE2 does a route lookup in the spoke VRF table and forwards the traffic to hub PE1 (through the P router—PE2 pushes two labels) using the default route learned through BGP.
spoke.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[BGP/170] 00:00:09, localpref 100, from 10.255.14.176 AS path: 100 I > via t3-0/0/0.0, Push 1029, Push 100224(top)Hub PE1 does a route lookup in the mpls.0 table for the VPN label
1029.mpls.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1029 *[VPN/0] 00:11:49 to table hub_downstream.inet.0, PopThe VPN label
1029is advertised because:The
vrf-table-labelstatement is applied at the[edit routing-instances hub_downsteam]hierarchy level in the hub PE1 configuration.The
no-vrf-advertisestatement is applied at the[edit routing-instances hub]hierarchy level, instructing the router to advertise the route from the secondary table.
Therefore, IP lookups are performed in the hub_downstream.inet.0 table, not in the hub.inet.0 table.
Issue the
show route advertising-protocolcommand on the hub PE to a spoke PE to verify the VPN label1029advertisement:user@host> show route advertising-protocol hub_downstream.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) * 0.0.0.0/0 (1 entry, 1 announced) BGP group ibgp type Internal Route Distinguisher: 10.255.14.176:3 VPN Label: 1029 Nexthop: Self Localpref: 100 AS path: 100 I Communities: target:200:101Hub PE1 performs an IP lookup in the
hub_downstream.inet.0table and forwards the traffic out interfacet3-0/0/0.0to hub CE1.hub_downstream.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) 0.0.0.0/0 (1 entry, 1 announced) *BGP Preference: 170/-101 Next-hop reference count: 4 Source: 10.49.4.2 Next hop: 10.49.4.2 via t3-0/0/0.0, selected State: <Secondary Active Ext> Peer AS: 100 Age: 3:03 Task: BGP_100.10.49.4.2+1707 Announcement bits (2): 0-KRT 2-BGP.0.0.0.0+179 AS path: 100 I Communities: target:200:101 Localpref: 100 Router ID: 10.49.10.251 Primary Routing Table hub.inet.0The primary routing table is
hub.inet.0, indicating that this route was exported from tablehub.inet.0into this hub_downstream.inet.0 table as a result of theno-vrf-advertisestatement at the[edit routing-instances hub]hierarchy level and theauto-exportstatement at the[edit routing-instances hub-downstream routing-options]hierarchy level in the hub PE1 configuration.Hub CE1 forwards the traffic back to hub PE1 using the router learned through BGP.
10.49.10.253/32 *[BGP/170] 02:40:03, localpref 100 AS path: 200 200 I > to 10.49.4.1 via t3-3/1/0.0Hub PE1 performs a route lookup in the hub VRF table and forwards the traffic to spoke PE3 (through the P router—PE1 pushes two labels).
10.49.10.253/32 *[BGP/170] 01:41:05, localpref 100, from 10.255.14.178 AS path: 100 I > via t1-0/1/0.0, Push 100128, Push 100192(top)Spoke PE3 performs a route lookup in the mpls.0 table for VPN label
100128.100128 *[VPN/170] 02:41:30 > to 10.49.6.2 via t3-0/0/0.0, PopSpoke PE3 forwards traffic out interface
t3-0/0/0.0to spoke CE3.
Configuring Hub-and-Spoke VPN Topologies: Two Interfaces
Use a two-interface configuration to propagate routes from spoke to spoke.
The example in this section configures a hub-and-spoke topology with two interfaces using the following components (see Figure 2):
One hub PE router (Router D).
One hub CE router connected to the hub PE router. For this hub-and-spoke VPN topology to function properly, there must be two interfaces connecting the hub PE router to the hub CE router, and each interface must have its own VRF table on the PE router:
The first interface (here, interface ge-0/0/0.0) is used to announce spoke routes to the hub CE router. The VRF table associated with this interface contains the routes being announced by the spoke PE routers to the hub CE router.
The second interface (here, interface ge-0/0/1.0) is used to receive route announcements from the hub CE that are destined for the hub-and-spoke routers. The VRF table associated with this interface contains the routes announced by the hub CE router to the spoke PE routers. For this example, two separate physical interfaces are used. It would also work if you were to configure two separate logical interfaces sharing the same physical interface between the hub PE router and the hub CE router.
Two spoke PE routers (Router E and Router F).
Two spoke CE routers (CE1 and CE2), one connected to each spoke PE router.
LDP as the signaling protocol.
In this configuration, route distribution from spoke CE Router CE1 occurs as follows:
Spoke Router CE1 announces its routes to spoke PE Router E.
Router E installs the routes from CE1 into its VRF table.
After checking its VRF export policy, Router E adds the spoke target community to the routes from Router CE1 that passed the policy and announces them to the hub PE router, Router D.
Router D checks the VRF import policy associated with interface ge-0/0/0.0 and places all routes from spoke PE routers that match the policy into its bgp.l3vpn routing table. (Any routes that do not match are discarded.)
Router D checks its VRF import policy associated with interface ge-0/0/0.0 and installs all routes that match into its spoke VRF table. The routes are installed with the spoke target community.
Router D announces routes to the hub CE over interface ge-0/0/0.
The hub CE router announces the routes back to the hub PE Router D over the second interface to the hub router, interface ge-0/0/1.
The hub PE router installs the routes learned from the hub CE router into its hub VRF table, which is associated with interface ge-0/0/1.
The hub PE router checks the VRF export policy associated with interface ge-0/0/1.0 and announces all routes that match to all spokes after adding the hub target community.
Figure 3 illustrates how routes are
distributed from this spoke router to the other spoke CE router, Router
CE2. The same path is followed if you issue a traceroute command from Router CE1 to Router CE2.
The final section in this example, Hub-and-Spoke VPN Configuration Summarized by Router, consolidates the statements needed to configure VPN functionality for each of the service provider routers shown in Figure 2.
The following sections explain how to configure the VPN functionality for a hub-and-spoke topology on the hub-and-spoke PE routers. The CE routers do not have any information about the VPN, so you configure them normally.
- Enabling an IGP on the Hub-and-Spoke PE Routers
- Configuring LDP on the Hub-and-Spoke PE Routers
- Configuring IBGP on the PE Routers
- Configuring VPN Routing Instances on the Hub-and-Spoke PE Routers
- Configuring VPN Policy on the PE Routers
- Hub-and-Spoke VPN Configuration Summarized by Router
Enabling an IGP on the Hub-and-Spoke PE Routers
To allow the hub-and-spoke PE routers to exchange routing information,
you must configure an IGP on all these routers or you must configure
static routes. You configure the IGP on the primary instance of the
routing protocol process (rpd) (that is, at the [edit protocols] hierarchy level), not within the routing instance (that is, not
at the [edit routing-instances] hierarchy level).
You configure the IGP in the standard way. This configuration example does not include this portion of the configuration.
In the route distribution in a hub-and-spoke topology, if the
protocol used between the CE and PE routers at the hub site is BGP,
the hub CE router announces all routes received from the hub PE router
and the spoke routers back to the hub PE router and all the spoke
routers. This means that the hub-and-spoke PE routers receive routes
that contain their AS number. Normally, when a route contains this
information, it indicates that a routing loop has occurred and the
router rejects the routes. However, for the VPN configuration to work,
the hub PE router and the spoke routers must accept these routes.
To enable this, include the loops option when configuring
the AS at the [edit routing-options] hierarchy level on
the hub PE router and all the spoke routers. For this example configuration,
you specify a value of 1. You can specify a number from 0
through 10.
[edit routing-options] autonomous-system as-number loops 1;
Configuring LDP on the Hub-and-Spoke PE Routers
Configure LDP on the interfaces between the hub-and-spoke PE routers that participate in the VPN.
On hub PE Router D, configure LDP:
[edit protocols]
ldp {
interface so-1/0/0.0;
interface t3-1/1/0.0;
}
On spoke PE Router E, configure LDP:
[edit protocols]
ldp {
interface fe-0/1/2.0;
}
On spoke PE router Router F, configure LDP:
[edit protocols]
ldp {
interface fe-1/0/0.0;
}
Configuring IBGP on the PE Routers
On the hub-and-spoke PE routers, configure an IBGP session with the following properties:
VPN family—To indicate that the IBGP session is for the VPN, include the
family inet-vpnstatement.Loopback address—Include the
local-addressstatement, specifying the local PE router’s loopback address. The IBGP session for VPNs runs through the loopback address. You must also configure thelo0interface at the[edit interfaces]hierarchy level. The example does not include this part of the router’s configuration.Neighbor address—Include the
neighborstatement. On the hub router, specify the IP address of each spoke PE router, and on the spoke router, specify the address of the hub PE router.
For the hub router, you configure an IBGP session with each spoke, and for each spoke router, you configure an IBGP session with the hub. There are no IBGP sessions between the two spoke routers.
On hub Router D, configure IBGP. The first neighbor statement configures an IBGP session to spoke Router E, and the
second configures a session to spoke Router F.
[edit protocols]
bgp {
group Hub-to-Spokes {
type internal;
local-address 10.255.14.174;
family inet-vpn {
unicast;
}
neighbor 10.255.14.180;
neighbor 10.255.14.182;
}
}
On spoke Router E, configure an IBGP session to the hub router:
[edit protocols]
bgp {
group Spoke-E-to-Hub {
type internal;
local-address 10.255.14.180;
neighbor 10.255.14.174 {
family inet-vpn {
unicast;
}
}
}
}
On spoke Router F, configure an IBGP session to the hub router:
[edit protocols]
bgp {
group Spoke-F-to-Hub {
type internal;
local-address 10.255.14.182;
neighbor 10.255.14.174 {
family inet-vpn {
unicast;
}
}
}
}
Configuring VPN Routing Instances on the Hub-and-Spoke PE Routers
For the hub PE router to be able to distinguish between packets going to and coming from the spoke PE routers, you must configure it with two routing instances:
One routing instance (in this example,
Spokes-to-Hub-CE) is associated with the interface that carries packets from the hub PE router to the hub CE router (in this example, interfacege-0/0/0.0). Its VRF table contains the routes being announced by the spoke PE routers and the hub PE router to the hub CE router.The second routing instance (in this example,
Hub-CE-to-Spokes) is associated with the interface that carries packets from the hub CE router to the hub PE router (in this example, interfacege-0/0/1.0). Its VRF table contains the routes being announced from the hub CE router to the hub-and-spoke PE routers.
On each spoke router, you must configure one routing instance.
You must define the following in the routing instance:
Route distinguisher, which is used to distinguish the addresses in one VPN from those in another VPN.
Instance type of
vrf, which creates the VRF table on the PE router.Interfaces that are part of the VPN and that connect the PE routers to their CE routers.
VRF import and export policies. Both import policies must include reference to a community. Otherwise, when you try to commit the configuration, the commit fails. (The exception to this is if the import policy contains only a
then rejectstatement.) In the VRF export policy, spoke PE routers attach the spoke target community.Routing between the PE and CE routers, which is required for the PE router to distribute VPN-related routes to and from connected CE routers. You can configure a routing protocol—BGP, OSPF, or RIP—or you can configure static routing.
For a hub-and-spoke topology, you must configure different policies
in each routing instance on the hub CE router. For the routing instance
associated with the interface that carries packets from the hub PE
router to the hub CE router (in this example, Spokes-to-Hub-CE), the import policy must accept all routes received on the IBGP
session between the hub-and-spoke PE routers, and the export policy
must reject all routes received from the hub CE router. For the routing
instance associated with the interface that carries packets from the
hub CE router to the hub PE router (in this example, Hub-CE-to-Spokes), the import policy must reject all routes received from the spoke
PE routers, and the export policy must export to all the spoke routers.
On hub PE Router D, configure the following routing instances. Router D uses OSPF to distribute routes to and from the hub CE router.
[edit]
routing-instance {
Spokes-to-Hub-CE {
instance-type vrf;
interface ge-0/0/0.0;
route-distinguisher 10.255.1.174:65535;
vrf-import spoke;
vrf-export null;
protocols {
ospf {
domain-id disable;
export redistribute-vpn;
domain-vpn-tag 0;
area 0.0.0.0 {
interface ge-0/0/0;
}
}
}
}
Hub-CE-to-Spokes {
instance-type vrf;
interface ge-0/0/1.0;
route-distinguisher 10.255.1.174:65534;
vrf-import null;
vrf-export hub;
protocols {
ospf {
export redistribute-vpn;
area 0.0.0.0 {
interface ge-0/0/1.0;
}
}
}
}
}
On spoke PE Router E, configure the following routing instances. Router E uses OSPF to distribute routes to and from spoke CE Router CE1.
[edit]
routing-instance {
Spoke-E-to-Hub {
instance-type vrf;
interface fe-0/1/0.0;
route-distinguisher 10.255.14.80:65035;
vrf-import hub;
vrf-export spoke;
protocols {
ospf {
export redistribute-vpn;
area 0.0.0.0 {
interface fe-0/1/0.0;
}
}
}
}
}
On spoke PE Router F, configure the following routing instances. Router F uses OSPF to distribute routes to and from spoke CE Router CE2.
[edit]
routing-instance {
Spoke-F-to-Hub {
instance-type vrf;
interface fe-1/0/1.0;
route-distinguisher 10.255.14.182:65135;
vrf-import hub;
vrf-export spoke;
protocols {
ospf {
export redistribute-vpn;
area 0.0.0.0 {
interface fe-1/0/1.0;
}
}
}
}
}
Configuring VPN Policy on the PE Routers
You must configure VPN import and export policies on each of the hub-and-spoke PE routers so that they install the appropriate routes in the VRF tables, which they use to forward packets within each VPN.
On the spoke routers, you define policies to exchange routes with the hub router.
On the hub router, you define policies to accept routes from the spoke PE routers and distribute them to the hub CE router, and vice versa. The hub PE router has two VRF tables:
Spoke-to-hub VRF table—Handles routes received from spoke routers and announces these routes to the hub CE router. For this VRF table, the import policy must check that the spoke target name is present and that the route was received from the IBGP session between the hub PE and the spoke PE routers. This VRF table must not export any routes, so its export policy should reject everything.
Hub-to-spoke VRF table—Handles routes received from the hub CE router and announces them to the spoke routers. For this VRF table, the export policy must add the hub target community. This VRF table must not import any routes, so its import policy should reject everything.
In the VPN policy, you also configure the VPN target communities.
On hub PE Router D, configure the following policies to apply to the VRF tables:
spoke—Accepts routes received from the IBGP session between it and the spoke PE routers that contain the community targetspoke, and rejects all other routes.hub—Adds the community target hub to all routes received from OSPF (that is, from the session between it and the hub CE router). It rejects all other routes.null—Rejects all routes.redistribute-vpn—Redistributes OSPF routes to neighbors within the routing instance.[edit] policy-options { policy-statement spoke { term a { from { protocol bgp; community spoke; } then accept; } term b { then reject; } } policy-statement hub { term a { from protocol ospf; then { community add hub; accept; } } term b { then reject; } } policy-statement null { then reject; } policy-statement redistribute-vpn { term a { from protocol bgp; then accept; } term b { then reject; } } community hub members target:65535:1; community spoke members target:65535:2; }
To apply the VRF policies on Router D, include the vrf-export and vrf-import statements when you configure the routing
instances:
[edit]
routing-instance {
Spokes-to-Hub-CE {
vrf-import spoke;
vrf-export null;
}
Hub-CE-to-Spokes {
vrf-import null;
vrf-export hub;
}
}
On spoke PE Router E and Router F, configure the following policies to apply to the VRF tables:
hub—Accepts routes received from the IBGP session between it and the hub PE routers that contain the community targethub, and rejects all other routes.spoke—Adds the community target spoke to all routes received from OSPF (that is, from the session between it and the hub CE router) rejects all other routes.redistribute-vpn—Redistributes OSPF routes to neighbors within the routing instance.
On spoke PE Router E and Router F, configure the following VPN import and export policies:
[edit]
policy-options {
policy-statement hub {
term a {
from {
protocol bgp;
community hub;
}
then accept;
}
term b {
then reject;
}
}
policy-statement spoke {
term a {
from protocol ospf;
then {
community add spoke;
accept;
}
}
term b {
then reject;
}
}
policy-statement redistribute-vpn {
term a {
from protocol bgp;
then accept;
}
term b {
then reject;
}
}
community hub members target:65535:1;
community spoke members target 65535:2;
}
To apply the VRF policies on the spoke routers, include the vrf-export and vrf-import statements when you configure
the routing instances:
[edit]
routing-instance {
Spoke-E-to-Hub {
vrf-import hub;
vrf-export spoke;
}
}
[edit]
routing-instance {
Spoke-F-to-Hub {
vrf-import hub;
vrf-export spoke;
}
}
Hub-and-Spoke VPN Configuration Summarized by Router
Router D (Hub PE Router)
Routing Instance for Distributing Spoke Routes to Hub CE
Spokes-to-Hub-CE {
instance-type vrf;
interface fe-0/0/0.0;
route-distinguisher 10.255.1.174:65535;
vrf-import spoke;
vrf-export null;
}
Instance Routing Protocol
protocols {
ospf {
domain-id disable;
domain-vpn-tag 0;
export redistribute-vpn;
area 0.0.0.0 {
interface ge-0/0/0.0;
}
}
}
Routing Instance for Distributing Hub CE Routes to Spokes
Hub-CE-to-Spokes {
instance-type vrf;
interface ge-0/0/1.0;
route-distinguisher 10.255.1.174:65534;
vrf-import null;
vrf-export hub;
}
Routing Instance Routing Protocols
protocols {
ospf {
export redistribute-vpn;
area 0.0.0.0 {
interface ge-0/0/1.0;
}
}
}
Routing Options (Primary Instance)
routing-options {
autonomous-system 1 loops 1;
}
Protocols (Primary Instance)
protocols {
}
Enable LDP
ldp {
interface so-1/0/0.0;
interface t3-1/1/0.0;
}
Configure IBGP
bgp {
group Hub-to-Spokes {
type internal;
local-address 10.255.14.174;
family inet-vpn {
unicast;
}
neighbor 10.255.14.180;
neighbor 10.255.14.182;
}
}
Configure VPN Policy
policy-options {
policy-statement spoke {
term a {
from {
protocol bgp;
community spoke;
}
then accept;
}
term b {
then reject;
}
}
policy-statement hub {
term a {
from protocol ospf;
then {
community add hub;
accept;
}
}
term b {
then reject;
}
}
policy-statement null {
then reject;
}
policy-statement redistribute-vpn {
term a {
from protocol bgp;
then accept;
}
term b {
then reject;
}
}
community hub members target:65535:1;
community spoke members target:65535:2;
}
Router E (Spoke PE Router)
Routing Instance
routing-instance {
Spoke-E-to-Hub {
instance-type vrf;
interface fe-0/1/0.0;
route-distinguisher 10.255.14.80:65035;
vrf-import hub;
vrf-export spoke;
}
}
Instance Routing Protocol
protocols {
ospf {
export redistribute-vpn;
area 0.0.0.0 {
interface fe-0/1/0.0;
}
}
}
Routing Options (Primary Instance)
routing-options {
autonomous-system 1 loops 1;
}
Protocols (Primary Instance)
protocols {
}
Enable LDP
ldp {
interface fe-0/1/2.0;
}
Configure IBGP
bgp {
group Spoke-E-to-Hub {
type internal;
local-address 10.255.14.180;
neighbor 10.255.14.174 {
family inet-vpn {
unicast;
}
}
}
}
Configure VPN Policy
policy-options {
policy-statement hub {
term a {
from {
protocol bgp;
community hub;
}
then accept;
}
term b {
then reject;
}
}
policy-statement spoke {
term a {
from protocol ospf;
then {
community add spoke;
accept;
}
}
term b {
then reject;
}
}
policy-statement redistribute-vpn {
term a {
from protocol bgp;
then accept;
}
term b {
then reject;
}
}
community hub members target:65535:1;
community spoke members target:65535:2;
}
Router F (Spoke PE Router)
Routing Instance
routing-instance {
Spoke-F-to-Hub {
instance-type vrf;
interface fe-1/0/1.0;
route-distinguisher 10.255.14.182:65135;
vrf-import hub;
vrf-export spoke;
}
}
Instance Routing Protocol
protocols {
ospf {
export redistribute-vpn;
area 0.0.0.0 {
interface fe-1/0/1.0;
}
}
}
Routing Options (Primary Instance)
routing-options {
autonomous-system 1 loops 1;
}
Protocols (Primary Instance)
protocols {
}
Enable LDP
ldp {
interface fe-1/0/0.0;
}
Configure IBGP
bgp {
group Spoke-F-to-Hub {
type internal;
local-address 10.255.14.182;
neighbor 10.255.14.174 {
family inet-vpn {
unicast;
}
}
}
}
Configure VPN Policy
policy-options {
policy-statement hub {
term a {
from {
protocol bgp;
community hub;
}
then accept;
}
term b {
then reject;
}
}
policy-statement spoke {
term a {
from protocol ospf;
then {
community add spoke;
accept;
}
}
term b {
then reject;
}
}
policy-statement redistribute-vpn {
term a {
from {
protocol bgp;
}
then accept;
}
term b {
then reject;
}
}
community hub members target:65535:1;
community spoke members target:65535:2;
}