Typically, when two service providers need to interconnect their autonomous systems and offer end-to-end services for multiple customers, they will use one of the three inter-AS option designs: Option A, Option B or Option C. In this post I will explore each of these options, explain their trade-offs and offer some helpful diagrams to visualize the packet flow.
Inter-AS Option A is also known as the “back to back VRF” option because it simply uses back to back vrf connections between the ASBR’s of the Service providers. This option is considered the simplest and most secure among the options where per-VPN filtering, accounting and policing can be applied easily. Each ASBR treat the facing link/VRF as a customer edge CE peer, where they exchange native IP forwarding between the two autonomous systems (no MPLS between the ASBR’s).
- Routing between the ASBR’s can be an IGP but eBGP is usually preferred as extended BGP communities can be used to maintain IGP metric transparency over the Inter-AS MPLS network
- OSPF has some technical consideration to take into account due to the behaviour of the DOWN bit on vrf enabled interfaces
- Scalability is an issue as the PE’s have to maintain all VRF routing tables
- No label exchange at the ASBR boundary (SP1-PE2 and SP2-PE1)
- Offers QoS granularity per VPN as the ASBR’s will have an interface/subinterface per VRF
- Operational complexity at the ASBR due to maintenance of each customer QoS/VPN configurations
Inter-AS Option B design is based on the concept of having an end to end labeled switched path to exchange all labels/VPNs between the providers.
There are three primary approaches in deploying the interconnect link to allow the transport of VPN prefixes at the ASBR’s.
- Next-Hop-Self (as seen in the diagram above)
- Redistribute connected at the ASBR’s
- Redistribute static routes using loopbacks of ASBR’s
- no-ARF in the diagram refers to no Automatic Route Filtering. This is required to disable Route Target filtering and enables the ASBR’s to accept VPNv4 prefixes. By default, when BGP receives a VPN route from another device, BGP will store the route in it’s local routing table only if at least one of the VRF imports a route target of that route. Generally, the intention is that BGP keeps track of routes only for directly connected VPN’s and discards all other VPN’s to conserve memory. There’s no need to have local VRF’s like in option A because of this feature.
- The reason we have to change the next hop with one of the 3 above mentioned methods is due to eBGP changing the next-hop of VPNv4 routes. Usually the internal PE routers won’t have reachability to the ASBR link between carriers so it’s important to change the next-hop to a reachable address.
- Some routers will require a /32 to forward labelled traffic, to fix this issue you will need to create a /32 host route to the neighboring IP to the directly connected ASBR link.
- ASBR’s (SP1-PE2 and SP2-PE1) will have all VPN prefixes which requires a lot of ressources. If scalability becomes an issue, you should use Option C.
- Per VPN QoS granularity is not as good as Option A but end-to-end MPLS EXP based QoS is simple due to the end to end LSP.
- Simplicity and Scalability is better than Option A but worst than Option C
Option C, also known as 2547bis Option C, is the most scalable solution of the Inter-AS connectivity designs as it exchanges VPNv4 prefixes like Option B but through Route Reflectors inside of each Service Provider autonomous system.
- no-NHS in the diagram refers to no Next Hop Self. It’s important to make sure the next-hop is unchanged on the eBGP session between the RR because without that the LSP will terminate on the RR and then be sent to the PE the PE causing suboptimal routing. In most cases, you don’t want your traffic to go through the RR as it is not the most optimal path to the destination.
- BGP-MH in the diagram refers to BGP Multi Hop. Let’s remember that this is an eBGP session and that the TTL will be set to 1 by default on the BGP session.
- ASBR’s are peering BGP but only exchanging transport labels (remote PE’s for BGP next-hop reachability of VPN routes)
- This option requires leaking of internal information (loopbacks) to peer between RR and therefore it is considered as the least secure option
- The most scalable of all options as only remote AS PE’s IP are maintained on the ASBR’s
- ASBR operational complexity is the lowest of all three options
Overall the trade-offs between all three options are between scalability, QoS granularity, security, operational complexity and end to end flexibility.