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]
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.
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.
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.
No special configuration beyond device initialization is required before configuring this example.
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.
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  hierarchy level.
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:
- Configure the interfaces.
To enable MPLS, include the protocol family on the interface so that the interface does not discard incoming MPLS traffic.[edit interfaces]user@PE1# set ge-1/2/0 unit 0 family inet address 10.0.0.2/30user@PE1# set ge-1/2/0 unit 0 family isouser@PE1# set ge-1/2/0 unit 0 family mplsuser@PE1# set ge-1/2/1 unit 0 family inet address 10.0.0.5/30user@PE1# set ge-1/2/1 unit 0 family isouser@PE1# set ge-1/2/1 unit 0 family mplsuser@PE1# set ge-1/2/2 unit 0 family inet address 10.0.0.21/30user@PE1# set ge-1/2/2 unit 0 family isouser@PE1# set ge-1/2/2 unit 0 family mplsuser@PE1# set lo0 unit 0 family inet address 10.255.2.2/32user@PE1# set lo0 unit 0 family iso address 49.0001.0010.0000.0202.00
- 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.[edit protocols]user@PE1# set mpls interface ge-1/2/2.0user@PE1# set mpls interface ge-1/2/1.0user@PE1# set mpls interface lo0.0user@PE1# set mpls interface fxp0.0 disableuser@PE1# set isis interface ge-1/2/1.0 level 2 metric 10user@PE1# set isis interface ge-1/2/1.0 level 1 disableuser@PE1# set isis interface ge-1/2/2.0 level 2 metric 10user@PE1# set isis interface ge-1/2/2.0 level 1 disableuser@PE1# set isis interface fxp0.0 disableuser@PE1# set isis interface lo0.0 level 2 metric 0user@PE1# set ldp deaggregateuser@PE1# set ldp interface ge-1/2/1.0user@PE1# set ldp interface ge-1/2/2.0user@PE1# set ldp interface fxp0.0 disableuser@PE1# set ldp interface lo0.0
- Enable the internal BGP (IBGP) connection to peer with
the RR only, using the IPv4 VPN unicast address family.[edit protocols bgp group l3vpn]user@PE1# set type internaluser@PE1# set local-address 10.255.2.2user@PE1# set family inet-vpn unicastuser@PE1# set peer-as 65534user@PE1# set local-as 65534user@PE1# set neighbor 10.255.4.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.[edit routing-instances VPN-A]user@PE1# set instance-type vrfuser@PE1# set interface ge-1/2/0.0user@PE1# set route-distinguisher 65534:1234user@PE1# set vrf-target target:65534:1234user@PE1# set protocols bgp group CE type externaluser@PE1# set protocols bgp group CE family inet unicastuser@PE1# set protocols bgp group CE neighbor 10.0.0.1 peer-as 64512user@PE1# set protocols bgp group CE neighbor 10.0.0.1 as-override
- Configure the router ID and the AS number.[edit routing-options]user@PE1# set router-id 10.255.2.2user@PE1# set autonomous-system 65534
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.
Confirm that the configuration is working properly.
Checking AS Path to the CE Devices
Display information on Device PE1 about the AS path attribute for the route to Device CE2’s loopback interface.
On Device PE1, from operational mode, enter the show route table VPN-A.inet.0 10.255.6.6 command.
user@PE1> show route table VPN-A.inet.0 10.255.6.6
VPN-A.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.255.6.6/32 *[BGP/170] 02:19:35, localpref 100, from 10.255.4.4 AS path: 64512 I, validation-state: unverified > to 10.0.0.22 via ge-1/2/2.0, Push 300032, Push 299776(top)
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
Make sure the route to Device CE2 is advertised to Device CE1 as if it is coming from the MPLS core.
On Device PE1, from operational mode, enter the show route advertising-protocol bgp 10.0.0.1 command.
user@PE1> show route advertising-protocol bgp 10.0.0.1
VPN-A.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 10.0.0.16/30 Self I * 10.255.1.1/32 10.0.0.1 65534 I * 10.255.6.6/32 Self 65534 I
The output indicates that Device PE1 is advertising only its own AS number in the AS path.
Checking the Route on Device CE1
Make sure that Device CE1 contains only the provider AS number in the AS path for the route to Device CE2.
From operational mode, enter the show route table inet.0 terse 10.255.6.6 command.
user@CE1> show route table inet.0 terse 10.255.6.6
inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both A V Destination P Prf Metric 1 Metric 2 Next hop AS path * ? 10.255.6.6/32 B 170 100 65534 65534 I unverified >10.0.0.2
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.
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.
The as-path-compare statement is not supported for the default routing instance.