Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

TechLibrary
Navigation

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 Interface

Example 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:

[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-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 {encapsulation frame-relay;unit 0 {dlci 16;family inet {address 10.49.4.1/30;}}}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;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;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:

  1. 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
  2. Spoke PE2 performs a route lookup in the spoke VRF table and forwards the traffic to hub PE2 (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)
  3. 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, Pop
  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.
        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.0
  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).
        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)
  3. 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, Pop
  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.
        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
  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.
        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)
  3. 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, Pop
  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.
        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.0
  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).
        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)
  7. 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, Pop
  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:

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:101

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:

1028               *[VPN/0] 00:00:27
                      to table hub.inet.0, Pop

However, 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;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;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 the routing instances configuration guidelines in the Junos OS Routing Protocols Configuration Guide 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 the routing instances configuration guidelines in the Junos OS Routing Protocols Configuration Guide 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.
        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
  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.
        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)
  3. 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, Pop

    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:

    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:101
  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.
        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.0

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

Published: 2012-11-29

Supported Platforms

Published: 2012-11-29

Previous Page Next Page