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

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