Configuring Aggregate Labels for VPNs
Aggregate labels for VPNs allow a Juniper Networks routing platform to aggregate a set of incoming labels (labels received from a peer router) into a single forwarding label that is selected from the set of incoming labels. The single forwarding label corresponds to a single next hop for that set of labels. Label aggregation reduces the number of VPN labels that the router must examine.
For a set of labels to share an aggregate forwarding label, they must belong to the same forwarding equivalence class (FEC). The labeled packets must have the same destination egress interface.
Including the community community-name statement with the aggregate-label statement lets
you specify prefixes with a common origin community. Set by policy
on the peer PE, these prefixes represent an FEC on the peer PE router.
If the target community is set by mistake instead of the origin community, forwarding problems at the egress PE can result. All prefixes from the peer PE will appear to be in the same FEC, resulting in a single inner label for all CE routers behind a given PE in the same VPN.
To work with route reflectors in Layer 3 VPN networks, the Juniper Networks M10i router aggregates a set of incoming labels only when the routes:
Are received from the same peer router
Have the same site of origin community
Have the same next hop
The next hop requirement is important because route reflectors forward routes originated from different BGP peers to another BGP peer without changing the next hop of those routes.
To configure aggregate labels for VPNs, include the aggregate-label statement:
aggregate-label { community community-name; }
For a list of hierarchy levels at which you can include this statement, see the statement summary for this statement.
For information about how to configure a community, see Understanding BGP Communities, Extended Communities, and Large Communities as Routing Policy Match Conditions.