Inter-AS Option B is a highly scalable, reasonably secure, but operationally complex inter-autonomous MPLS VPN architecture.
For those who want to understand the easiest, most flexible, and most secure Inter-AS solution, which is Inter-AS Option A please click here.
I am explaining this topic in deep detail in my Onsite CCDE, Live/Webex CCDE, and Self-Paced CCDE course.
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 protocols 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 reflectors 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 MP-BGP 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. MP-BGP is 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 the local BGP route reflector to the other service provider through MP-BGP VPNv4 session.
You do not need to keep the 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 are much less than those of Inter-AS Option A.
PE devices have BGP VPNv4 sessions with the Service Provider's Route Reflectors. PE redistributes customer VPN prefixes fromPE-CE routing protocol to MP-BGP and vice versa.
Route-target extended community is placed on the VPNv4 update. Route Target helps to place the VPN prefixes in the 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 a VPN update is sent to the VPNv4 route reflector.
The 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 the MP-BGP route into VRF, since it does not have to keep the VRF table but to maintain the VPNv4 BGP table in Inter-AS Option B.
By changing the next hop, ASBR from SP-A sends VPNv4 prefixes through the MP-BGP session to SP-B ASBR.
SP-B ASBR sends the customer prefixes to its local route reflector.
The next hop is changed on ASBR. (Normally EBGP to IBGP, next hop doesn't change).
Thus, either ASBR to ASBR link is redistributed into the 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, a new VPN label is assigned on that router for all VPN prefixes.
Caveat :
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 a route target associated with VRF.
Inter-AS Option B requires MP-BGP between autonomous systems. The VPN address family is enabled on the 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 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.
To have a great understanding of SP Networks, you can check my newly published SP Book. It covers the SP network Technologies with also explaining in detail a factious SP network.