[an error occurred while processing this directive][an error occurred while processing this directive]

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 1):

  • 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 1: Example of a Hub-and-Spoke VPN Topology with Two Interfaces

Image g017179.gif

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 2 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, Configuring Hub-and-Spoke VPN Topologies: Two Interfaces, consolidates the statements needed to configure VPN functionality for each of the service provider routers shown in Figure 1.

Figure 2: Route Distribution Between Two Spoke Routers

Image g017184.gif

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

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

[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 {export redistribute-vpn;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:65535;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:65535;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:65535;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 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.
    [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 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:

[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

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;}}

Instance Routing Protocol

protocols {ospf {export redistribute-vpn;area 0.0.0.0 {interface ge-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:65535;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 (Master Instance)

routing-options {autonomous-system 1 loops 1;}

Protocols (Master 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:65535;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 (Master Instance)

routing-options {autonomous-system 1 loops 1;}

Protocols (Master 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:65535;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 (Master Instance)

routing-options {autonomous-system 1 loops 1;}

Protocols (Master 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;}

Published: 2010-04-27

[an error occurred while processing this directive]