Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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: Example of a Hub-and-Spoke VPN Topology with One InterfaceExample of a Hub-and-Spoke VPN Topology with One Interface

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:

  1. Spoke CE2 advertises its routes to spoke PE2.

  2. Spoke PE2 installs routes from CE2 into its VPN routing and forwarding (VRF) table.

  3. Spoke PE2 checks its VRF export policy, adds the route target community, and announces the routes to hub PE1.

  4. Hub PE1 checks its VRF import policy and installs routes that match the import policy into table bgp.l3vpn.0.

  5. Hub PE1 installs routes from table bgp.l3vpn.0 into the hub VRF table.

  6. Hub PE1 announces routes from the hub VRF table to the hub CE1.

In this configuration example, default route distribution is as follows:

  1. Hub CE1 announces a default route to hub PE1.

  2. Hub PE1 installs the default route into the hub VRF table.

  3. Hub PE1 checks its VRF export policy, adds the route target community and announces the default route to spoke PE2 and PE3.

  4. Spoke PE2 and PE3 check their VRF import policy and install the default route into table bgp.l3vpn.0.

  5. Spoke PE2 and PE3 install the routes from table bgp.l3vpn.0 into their spoke VRF tables.

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

Configure hub CE1 as follows:

Configuring Hub PE1

Configure hub PE1 as follows:

Configuring the P Router

Configure the P Router as follows:

Configuring Spoke PE2

Configure spoke PE2 as follows:

Configuring Spoke PE3

Configure spoke PE3 as follows:

Configuring Spoke CE2

Configure spoke CE2 as follows:

Configuring Spoke CE3

Configure spoke CE3 as follows:

In this configuration example, traffic forwarding is as follows between spoke CE2 and hub CE1:

  1. Spoke CE2 forwards traffic using the default route learned from spoke PE2 through BGP.

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

  3. Hub PE1 does a route lookup in the mpls.0 table for the VPN label 100336.

  4. Hub PE1 forwards the traffic out the interface t3-0/0/0.0 to hub CE1.

In this configuration example, traffic forwarding is as follows between hub CE1 and spoke CE2:

  1. Hub CE1 forwards traffic to the hub PE1 using the route learned through BGP.

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

  3. Spoke PE2 does a route lookup in the mpls.0 table for the VPN label 100352.

  4. Spoke PE2 forwards the traffic out the interface t1-0/1/2.0 to spoke CE2.

In this configuration example, traffic forwarding is as follows between spoke CE2 and spoke CE3:

  1. Spoke CE2 forwards traffic using the default route learned from spoke PE2 through BGP.

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

  3. Hub PE1 does a route lookup in the mpls.0 table for the VPN label 100336.

  4. Hub PE1 forwards the traffic out the interface t3-0/0/0.0 to the hub CE1.

  5. Hub CE1 forwards the traffic to hub PE1 using the router learned through BGP.

  6. Hub 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).

  7. Spoke PE3 does a route lookup in the mpls.0 table for VPN label 100128.

  8. Spoke PE3 forwards the traffic out the interface t3-0/0/0.0 to 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:

Incoming traffic is forwarded using VPN label 1028. The mpls.0 table shows that an IP lookup in the table hub.inet.0 is required:

However, the hub VRF table hub.inet.0 contains specific spoke routes:

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:

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:

  1. Spoke CE2 forwards traffic using the default route learned from spoke PE2 through BGP.

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

  3. Hub PE1 does a route lookup in the mpls.0 table for the VPN label 1029.

    The VPN label 1029 is advertised because:

    1. The vrf-table-label statement is applied at the [edit routing-instances hub_downsteam] hierarchy level in the hub PE1 configuration.

    2. The no-vrf-advertise statement 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-protocol command on the hub PE to a spoke PE to verify the VPN label 1029 advertisement:

  4. Hub PE1 performs an IP lookup in the hub_downstream.inet.0 table and forwards the traffic out interface t3-0/0/0.0 to hub CE1.

    The primary routing table is hub.inet.0, indicating that this route was exported from table hub.inet.0 into this hub_downstream.inet.0 table as a result of the no-vrf-advertise statement at the [edit routing-instances hub] hierarchy level and the auto-export statement at the [edit routing-instances hub-downstream routing-options] hierarchy level in the hub PE1 configuration.

  5. Hub CE1 forwards the traffic back to hub PE1 using the router learned through BGP.

  6. Hub 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).

  7. Spoke PE3 performs a route lookup in the mpls.0 table for VPN label 100128.

  8. Spoke PE3 forwards traffic out interface t3-0/0/0.0 to 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.

Figure 2: Example of a Hub-and-Spoke VPN Topology with Two InterfacesExample of a Hub-and-Spoke VPN Topology with Two Interfaces

In this configuration, route distribution from spoke CE Router CE1 occurs as follows:

  1. Spoke Router CE1 announces its routes to spoke PE Router E.

  2. Router E installs the routes from CE1 into its VRF table.

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

  4. 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.)

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

  6. Router D announces routes to the hub CE over interface ge-0/0/0.

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

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

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

Figure 3: Route Distribution Between Two Spoke RoutersRoute Distribution Between Two Spoke Routers

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

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.

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:

On spoke PE Router E, configure LDP:

On spoke PE router Router F, configure LDP:

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-vpn statement.

  • Loopback address—Include the local-address statement, specifying the local PE router’s loopback address. The IBGP session for VPNs runs through the loopback address. You must also configure the lo0 interface at the [edit interfaces] hierarchy level. The example does not include this part of the router’s configuration.

  • Neighbor address—Include the neighbor statement. 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.

On spoke Router E, configure an IBGP session to the hub router:

On spoke Router F, configure an IBGP session to the hub router:

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, interface ge-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, interface ge-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 reject statement.) 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.

On spoke PE Router E, configure the following routing instances. Router E uses OSPF to distribute routes to and from spoke CE Router CE1.

On spoke PE Router F, configure the following routing instances. Router F uses OSPF to distribute routes to and from spoke CE Router CE2.

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 target spoke, 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.

To apply the VRF policies on Router D, include the vrf-export and vrf-import statements when you configure the routing instances:

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 target hub, 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:

To apply the VRF policies on the spoke routers, include the vrf-export and vrf-import statements when you configure the routing instances:

Hub-and-Spoke VPN Configuration Summarized by Router

Router D (Hub PE Router)

Routing Instance for Distributing Spoke Routes to Hub CE

Instance Routing Protocol

Routing Instance for Distributing Hub CE Routes to Spokes

Routing Instance Routing Protocols

Routing Options (Primary Instance)

Protocols (Primary Instance)

Enable LDP

Configure IBGP

Configure VPN Policy

Router E (Spoke PE Router)

Routing Instance

Instance Routing Protocol

Routing Options (Primary Instance)

Protocols (Primary Instance)

Enable LDP

Configure IBGP

Configure VPN Policy

Router F (Spoke PE Router)

Routing Instance

Instance Routing Protocol

Routing Options (Primary Instance)

Protocols (Primary Instance)

Enable LDP

Configure IBGP

Configure VPN Policy