Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Configuring an AS for Layer 3 VPNs

Configuring Layer 3 VPNs to Carry IBGP Traffic

An independent AS domain is separate from the primary routing instance domain. An AS is a set of routers that are under a single technical administration and that generally use a single IGP and metrics to propagate routing information within the set of routers. An AS appears to other ASs to have a single, coherent interior routing plan and presents a consistent picture of what destinations are reachable through it.

Configuring an independent domain allows you to keep the AS paths of the independent domain from being shared with the AS path and AS path attributes of other domains, including the master routing instance domain.

If you are using BGP on the router, you must configure an AS number.

When you configure BGP as the routing protocol between a PE router and a CE router in a Layer 3 VPN, you typically configure external peering sessions between the Layer 3 VPN service provider and the customer network ASs.

If the customer network has several sites advertising routes through an external BGP session to the service provider network and if the same AS is used by all the customer sites, the CE routers reject routes from the other CE routers. They detect a loop in the BGP AS path attribute.

To prevent the CE routers from rejecting each other’s routes, you could configure the following:

  • PE routers advertising routes received from remote PE routers can remap the customer network AS number to its own AS number.

  • AS path loops can be configured.

  • The customer network can be configured with different AS numbers at each site.

These types of configurations can work when there are no BGP routing exchanges between the customer network and other networks. However, they do have limitations for customer networks that use BGP internally for purposes other than carrying traffic between the CE routers and the PE routers. When those routes are advertised outside the customer network, the service provider ASs are present in the AS path.

To improve the transparency of Layer 3 VPN services for customer networks, you can configure the routing instance for the Layer 3 VPN to isolate the customer’s network attributes from the service provider’s network attributes.

When you include the independent-domain statement in the Layer 3 VPN routing instance configuration, BGP attributes received from the customer network (from the CE router) are stored in a BGP attribute (ATTRSET) that functions like a stack. When that route is advertised from the remote PE router to the remote CE router, the original BGP attributes are restored. This is the default behavior for BGP routes that are advertised to Layer 3 VPNs located in different domains.

This functionality is described in the Internet draft draft-marques-ppvpn-ibgp-version.txt, RFC 2547bis Networks Using Internal BGP as PE-CE Protocol.

To allow a Layer 3 VPN to transport IBGP traffic, include the independent-domain statement:

You can include this statement at the following hierarchy levels:

  • [edit routing-instances routing-instance-name routing-options autonomous-system number]

  • [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options autonomous-system number]

    Note:

    All PE routers participating in a Layer 3 VPN with the independent-domain statement in its configuration must be running Junos OS Release 6.3 or later.

Note:

The [edit logical-systems] hierarchy level is not applicable in ACX Series routers.

The independent domain uses the transitive path attribute 128 (attribute set) to tunnel the independent domain’s BGP attributes through the Internal BGP (IBGP) core. In Junos OS Release 10.3 and later, if BGP receives attribute 128 and you have not configured an independent domain in any routing instance, BGP treats the received attribute 128 as an unknown attribute.

There is a limit of 16 ASs for each domain.

See Also

Example: Configuring a Layer 3 VPN with Route Reflection and AS Override

Suppose that you are a service provider providing a managed MPLS-based Layer 3 VPN service. Your customer has several sites and requires BGP routing to customer edge (CE) devices at each site.

Requirements

No special configuration beyond device initialization is required before configuring this example.

Overview

This example has two CE devices, two provider edge (PE) devices, and several provider core devices. The provider network is also using IS-IS to support LDP and BGP loopback reachability Device P2 is acting as a route reflector (RR). Both CE devices are in autonomous system (AS) 64512. The provider network is in AS 65534.

The as-override statement is applied to the PE devices, thus replacing the CE device's AS number with that of the PE device. This prevents the customer AS number from appearing more than once in the AS path attribute.

Figure 1 shows the topology used in this example.

Figure 1: AS Override TopologyAS Override Topology

CLI Quick Configuration shows the configuration for all of the devices in Figure 1. The section Step-by-Step Procedure describes the steps on Device PE1.

Topology

Configuration

Procedure

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Device CE1

Device P1

Device P2

Device P3

Device PE1

Device PE2

Device CE2

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure AS override:

  1. Configure the interfaces.

    To enable MPLS, include the protocol family on the interface so that the interface does not discard incoming MPLS traffic.

  2. Add the interface to the MPLS protocol to establish the control plane level connectivity.

    Set up the IGP so that the provider devices can communicate with each other.

    To establish a mechanism to distribute MPLS labels, enable LDP. Optionally, for LDP, enable forwarding equivalence class (FEC) deaggregation, which results in faster global convergence.

  3. Enable the internal BGP (IBGP) connection to peer with the RR only, using the IPv4 VPN unicast address family.

  4. Configure the routing instance, including the as-override statement.

    Create the routing-Instance (VRF) on the PE device, setting up the BGP configuration to peer with Device CE1.

  5. Configure the router ID and the AS number.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show routing-instances, and show routing-options commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Checking AS Path to the CE Devices

Purpose

Display information on Device PE1 about the AS path attribute for the route to Device CE2’s loopback interface.

Action

On Device PE1, from operational mode, enter the show route table VPN-A.inet.0 10.255.6.6 command.

Meaning

The output shows that Device PE1 has an AS path for 10.255.6.6/32 as coming from AS 64512.

Checking How the Route to Device CE2 Is Advertised

Purpose

Make sure the route to Device CE2 is advertised to Device CE1 as if it is coming from the MPLS core.

Action

On Device PE1, from operational mode, enter the show route advertising-protocol bgp 10.0.0.1 command.

Meaning

The output indicates that Device PE1 is advertising only its own AS number in the AS path.

Checking the Route on Device CE1

Purpose

Make sure that Device CE1 contains only the provider AS number in the AS path for the route to Device CE2.

Action

From operational mode, enter the show route table inet.0 terse 10.255.6.6 command.

Meaning

The output indicates that Device CE1 has a route to Device CE2. The loop issue is resolved with the use of the as-override statement.

One route is hidden on the CE device. This is because Junos OS does not perform a BGP split horizon. Generally, split horizon in BGP is unnecessary, because any routes that might be received back by the originator are less preferred due to AS path length (for EBGP), AS path loop detection (IBGP), or other BGP metrics. Advertising routes back to the neighbor from which they were learned has a negligible effect on the router's performance, and is the correct thing to do.

See Also

Configuring the Algorithm That Determines the Active Route to Evaluate AS Numbers in AS Paths for VPN Routes

By default, the third step of the algorithm that determines the active route evaluates the length of the AS path but not the contents of the AS path. In some VPN scenarios with BGP multiple path routes, it can also be useful to compare the AS numbers of the AS paths and to have the algorithm select the route whose AS numbers match.

To configure the algorithm that selects the active path to evaluate the AS numbers in AS paths for VPN routes:

  • Include the as-path-compare statement at the [edit routing-instances routing-instance-name routing-options multipath] hierarchy level.

Note:

The as-path-compare statement is not supported for the default routing instance.