Manipulating the AS

Within Junos several tools are available to manipulate the AS Path, which can be useful when BGP is deployed as a PE to CE routing protocol across multiple VPN sites. Due to the built in loop prevention mechanisms of BGP a VPN site announcing a BGP route into a VRF may cause an AS loop to be detected if the route is advertised into the same AS number again in another VPN site. In order to overcome this limitation several features are available in Junos.

AS Override

AS Override is used by a BGP speaker (normally a PE router) to replace a remote AS number with the AS number of the local router receiving the route. The route is then advertised further downstream with two AS numbers in the path that are identical. This feature is often used in MPLS networks that are providing connectivity to a single AS that is distributed geographically across multiple VPN sites.

Depending on the requirements AS Override can be configured under the BGP global configuration, group configuration or neighbour configuration. The following configuration is an example of the group configuration overriding the remote AS of 2 with the local AS of 1.

protocols {
bgp {
group ASN1 {
neighbor 1.1.1.2 {
local-address 1.1.1.1;
family inet {
unicast;
}
as-override;
peer-as 2;
}
}
}
}

AS Loops

AS Loops is another approach that can be used to overcome the limitations of AS path loops when multiple VPN sites are announcing BGP routes from the same AS. The feature allows a CE device to accept a BGP route that has been advertised with the CE routers’ local AS in the path.

The following example demonstrates how the AS loops function is configured on the CE router. The command will instruct the CE to receive routes with its local AS in the path x amount of times.

protocols {
bgp {
group ASN2 {
neighbor 1.1.1.1 {
local-address 1.1.1.2;
family inet {
unicast;
}
autonomous-system loops 1;
peer-as 1;
}
}
}
}

Configuration is also required on the PE router, to allow the PE to announce a BGP route to a neighbour that is already in the AS path.

protocols {
bgp {
group ASN1 {
neighbor 1.1.1.2 {
local-address 1.1.1.1;
family inet {
unicast;
}
advertise-peer-as;
peer-as 2;
}
}
}
}

 

Internet Access Options

According to RFC4364 there are several methods for access the public internet using MPLS VPNs. Each approach utilities either “VRF aware” or “non VRF aware” procedures for delivering Internet access to a CE device.

Option 1.1 (Third Party Provider)

In this scenario the provider simply does not participate in any Internet gateway service and the access is provided by a third party network.

Option 1.2 (PE provides Layer 2 VPN towards Internet Gateway)

In this scenario a separate peering router is used to connect the providers network to the Internet. Access to the customer CE is provided using an MPLS layer 2 VPN, using CCC Ethernet encapsulation to present the attachment circuit to the CE. The attachment circuit does not necessarily need to be connected on a separate physical interface as it can be presented as a different logical interface over the customers existing circuit.

Option 2.1 (Separate interfaces for VPN and Internet Gateway)

In this scenario the CE router connects to the PE using two separate logical interfaces. The interface that connects to the Internet is part of the global routing table on both the CE and PE and thus makes it non VRF aware. A second VRF aware interface is also connected between the CE and PE to carry the customers VPN routes as part of their internal routing domain.

The PE carries all customer public routes within its global routing table and advertises them to the Internet. A default route, or full or partial Internet table is advertised from the PE to the CE over the non VRF aware interface. Using a rib-group (or static route with a next-hop table statement) each CE that requires Internet access exports the default route into the internal VPN and also in order to provide inbound routing from the Internet the customer public address space would be exported from the internal VPN into the CEs global routing table.

Option 2.2 (Internet routes within the VRF table on the PE)

In this scenario the CE router again connects to the PE using two separate logical interfaces, one non VRF aware and one VRF aware. All outbound traffic is carried over the VRF aware interface and when it arrives at the PE a default static route is configured to direct the outbound traffic to the global routing table using the next-hop table statement.

Traffic arriving at the PE from the Internet is directed to the CE over the non VRF aware interface. Either a rib-group or static next-hop table configuration routes traffic towards the customer VPN table.

Option 2.3 (Single interface for VPN and Internet access)

In this scenario a single VRF aware interface is used between the CE and the PE. All public and private routes are carried within the VPN and if BGP is used between the CE and PE the public routes can be tagged with community so when they arrive at the PE they can be exported into the global routing table using a rib-group that matches on this community. All other private VPN routes are carried within the customer domain.

In order to carry outbound traffic outside of the customer VRF a default route with a next-hop table statement is configured on the PE. The next-hop table is configured as the global routing table which allows outbound traffic to reach the Internet.

Option 3 (Central hub site with separate interfaces for VPN and Internet gateway)

In this scenario a central CE router is used to connect a non VRF and a VRF interface to the PE router. For outbound traffic a default route is generated by the PE in its global routing table and sent to the central CE over the non VRF interface. The default route is then set a next-hop table from with the CEs VRF table; this default state route is also advertised to all route CEs within the VPN to provide outbound connectivity for the whole VPN domain.

Inbound traffic is routed to the PE within its global routing tables and customer Internet routes are advertised by the central CE towards the PE using the non VRF interface. The central CE then use the next-hop table statement to forward inbound Internet traffic into the VPN tables to provide connectivity for the rest of the VPN domain.

BGP Independent Domain

What Exactly Does This Feature Do?

Imagine a scenario where a service provider has a requirement to peer their PE to a remote device using iBGP, and this remote device could be a customer CE, or a third party router that needs to send traffic across the service provider core to another remote site.

As the customer routes are sent over the provider core, the service providers AS would be added to the AS path of the customer routes, before these routes are announced to the end site.

There are two issues with this setup. Firstly the BGP Split Horizon rule the would prevent the routes from being announced to the remote site, as the customer AS would already exist in the path. The second issue could be that the provider (or customer) may wish for the routes to announced transparently between the two end points, without the provider AS being seen in the path.

How To Implement An Independant Domain

The VRF on the PE router is configured with the CE routers AS number, however this AS is not carried within the AS path attribute when the customer prefixes are carried across the providers core.

The reason for the above is due to the customer AS being removed from the AS path attribute and added into another attribute called ATTRSET; this effectively means that the customer AS is carried independently through the providers core, and does not affect the AS path used within the providers MPLS network.

When the routes arrive at a remote PE that is configured with the BGP independent domain, the original customer AS is taken from the ATTRSET, and replaced back into the AS path.

Configuration Example

The configuration is applied to the customer VRF under the routing-options heirarchy. The “independent-domain” command is appended to the AS number of the VRF, which in this case is 65501.

The command should be applied at all PE routes that are forming part of the VPN, and independent domain.

routing-instances {
vpn-a {
instance-type vrf;
route-distinguisher 172.21.0.2:4;
vrf-import vpn-a-import;
vrf-export vpn-a-export;
routing-options {
autonomous-system 65501 independent-domain;
}
}
}

Wrapping It Up

This feature is a pretty straight forward way of getting around a problem, however in most operational scenario’s it would probably be more wise to use some sort of layer 2 connection and allow the customer to peer directly between the two end points.

If the remote device is a managed CE, then there might be a case to use BGP independent domain, however other methods offer similar solutions such as AS-override, which I’ll be discussing in another article.

 

Auto Export

The auto-export feature is used when a PE router has multiple instances of the same VPN configured. This could be in a situation where two remote sites are connected to the PE within the same VPN but without connectivity between each other. The only way to establish connectivity in normal operation would be through BGP but this is not possible in this situation.

Auto export can be configured on each of the VRFs to allow automatically route leaking between any VRFs that have matching route target communities.

A single VRF configuration is shown below. The configuration should match on both VRFs on the PE.

routing-instances {
vpn-a {
instance-type vrf;
interface ge-0/0/0;
vrf-target target:65001:100;
routing-options {
auto-export;
}
protocols {
bgp {
group ce-1 {
peer-as 65002;
as-override;
neighbor 10.10.10.10;
}
}
}
}
}