Inter AS Option B is highly scalable, reasonably secure, but operationally complex inter autonomous MPLS VPN architecture.
For those who want to understand the easiest, flexible and most secure Inter AS solution , which is Inter AS Option A please click here.
First, I will explain how Inter AS Option B works. After that, I will cover the design considerations for Inter AS Option B.
I will use fig.1 to explain Inter AS Option B.
Figure 1 : Inter AS Option B
In the topology shown above in fig.1, AS10 and AS20 are the service providers.
There are two customers, VPNA and VPN B
NOTE: All the customers of the service providers could run different routing protocol at different sites. For example, while customer VPNA connected to AS10 is running OSPF, VPN A connected to AS20 could run EIGRP.
In the service provider network, PE routers are connected to the customer locations. PE routers run MP-BGP with route reflector to advertise VPNv4 prefixes.
PE router that connects the two providers at the edge is known as ASBR (Autonomous System Boundary Router).
Since ASBR runs MPBGP with RR as well, ASBR learns all the VPN routes from Inter AS customers.
As for Inter AS Option A, separate sub interfaces are enabled, and IGP protocols run between ASBRs. MPBGP are redistributed into IGP.
Inter AS Option B does not require separate sub interfaces and different IGP protocols or BGP per sub interfaces between the ASBRs.
Between the ASBRs, MP-BGP enables the VPNv4 address family.
ASBRs (Autonomous System Boundary Routers) advertise the customer prefixes which are learned from local BGP route reflector, to the another service provider through MP-BGP VPNv4 session.
You do not need to keep VRF table for the customers on the ASBRs. That is why there is no VRF on PE, as shown in fig.1.
You just need to keep the customer prefixes in the LFIB database.
CPU and memory requirements for Inter AS Option B is much less than those of Inter AS Option A.
PE devices have BGP VPNv4 session with the Service Provider’s Route Reflectors. PE redistributes customer VPN prefixes from
PE-CE routing protocol to MP-BGP and vice versa.
Route-target extended community is placed on the VPNv4 update. Route Target help to place the VPN prefixes to appropriate VRF.
When PE receives the customer IP prefixes, it changes next hop as themselves, Customer IP prefixes are made VPN prefixes by adding Route Distinguisher and VPN update is sent to the VPNv4 route reflector.
Route reflector does not change the next hop; rather, it only reflects the route to the ASBR. (This is normal BGP RR behavior but it is different in Option C)
ASBR does not place MP-BGP route into VRF, since it does not have to keep VRF table but to maintain VPNv4 BGP table in Inter AS Option B.
By changing the next hop, ASBR from SP-A sends VPNv4 prefixes through MP-BGP session to SP-B ASBR.
SP-B ASBR sends the customer prefixes to its local route reflector.
Next hop is changed on ASBR. (Normally EBGP to IBGP, next hop doesn’t change).
Thus, either ASBR to ASBR link is redistributed into global IGP table of service providers, or “next-hop self” is enabled in order to change the next hop as ASBR.
Route reflector in the SP-B domain reflects the prefixes as is, send to the PE which is connected to Customer A2 location.
SP-B PE sets the next hop again and sends the prefixes to the customer A2 router.
As shown in the service provider domains, there are three LSP.
Because changing the BGP next hop terminates the LSP, new VPN label is assigned on that router for all VPN prefixes.
Normally ASBR would not accept the VPN prefixes because they do not have VRF for the customers.
Since ASBRs do not have a VRF and the Route Target is not associated with the VRF in Option B, they would reject the prefixes.
As shown in fig.1, “no bgp route-target filter” configuration knob is enabled.
This configuration command allows the ASBRs to accept the VPN prefixes even though they do not have route target associated with VRF.
Inter AS Option B requires MP-BGP between autonomous systems. VPN address family is enabled on MP-BGP session.
Inter AS Option B does not require LDP or IGP protocols; thus service providers do not need to understand the internal addressing structure of one another.
LSP is not an end-to-end but it is terminated at many points; as a result, it is very difficult to manage.
Similar to Inter AS Option A, you do not need to redistribute VPN prefixes at the ASBR.
Route reflectors store all the VPN routing information for each customer, and they advertise those prefixes to ASBR.
Operators need to manage MP-BGP on the ASBRs as well as on the route reflectors.
What if by removing those prefixes from ASBRs, can we advertise all the VPN prefixes directly between route reflectors?
To answer this question, peruse the next article on Inter AS Option C.