[Contents] [Prev] [Next] [Index] [Report an Error]

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

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

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 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, 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
```

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.

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

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)

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

Spoke PE3 forwards traffic out interface t3-0/0/0.0 to spoke CE3.

[Contents] [Prev] [Next] [Index] [Report an Error]