InterAS for 6VPE

Inter AS for IPv6 VRF.
Version 1.1. By Fred Bovy ccie #3013
02/07/14
3 basic Scenario exists to cover all the needs. These models can be adapted to
cover all the needs of interconnection of MPLS-VPN Backbones. In IPv4 this is
also supported and it is tested with IPv6 and IPv4 or IPv6 only.
Illustration 1: MPLS-VPN
1. Control Plane Common to all configurations
The CE advertises an IPv6 route to the 6VPE with eBGP or another Routing Protocol. The 6VPE
received the routes and prepend the Route Descriptor before importing it in the BGP vpnv6 Addressfamily.
The Route-Targets configured for exports are added to the BGP vpnv6 path. Then it can advertises the
BGP vpnv6 path to the other 6VPE directly or via a Route-Reflector.
The remote 6VPE receives the BGP vpnv6 Path and checks the Route-Target of the path. If a VRF is
configured to import this RT, it creates an entry in the vpnv6 table with the IPv6 addresss and the VRF
default RD unless RD are the same.
It imports the route, removes the RD before it imports the best routes in the RIB if there are multiple
candidates in the VRF RIB (Route Information Base or Routing Table).
A MP-BGP Path which is not imported in any path is dropped by default unless BGP is configured to
keep all paths.
The new route is checked if it must be advertised by a Routing Protocol to the CE
2. Data plane common to all configurations.
The packet leaves the CE as a regular IPv6 Packet.
The Ingress 6VPE receives an IPv6 packet from the CE with an IPv6 destination in the VRF. The
interface on the 6VPE is configured with a VRF. The received packet destination address is checked
with the VRF FIB to see if the packet can be switched by CEFv6.
For more details about CEFv6 Please go to:
http://www.ipv6forlife.com/Docs/CEFv6InaNutshell.pdf
If the Forwarding Entry is present (FIB) but no MAC Address in the Adjacency table, the packet is
buffered while Neighbor Discovery Protocol make the MAC Address Resolution (NS/NA). A minimum
of two packets must be buffered.
If the Forwarding Entry is not there because there is no route then the packet is dropped and an
ICMPv6 packet is sent to the source.
So if CEFv6 is able to switch the packet it is also responsible to do the MPLS label imposition. You can
verify this with ther command “show ip cef vrf <vrf name> x:x:x:x:x:x:x:x/y internal”. Please see CEFv6 in a Nutshell for more details about CEFv6 at the end of this paper.
Two labels must be imposed , the Internal label is allocated and sent by the Egress 6VPE for this
destination. The External label is derived from LDP or RSVP.
The egress 6VPE switch the packet based on the MP-BGP label it has advertised and allocated for this
destination.
2. Scenario A
2.1 When should we use Scenario A?
This is the favorite Scenario when two service providers want to join their MLPS-VPN for a few
customers who use both SPs. The two MPLS-VPN backbone are fully separated. IP is used between the
2 Backbones, not MPLS.
Scenario A is good when you do not have much VRF to interconnect and you want to keep maximum
control over the interconnection. You can for instance enforce a SLA end to end easily. You need two
back to back 6VPEs. Each one thinks it connects a CE while it is connected to the VRF interface of the
other 6VPE. You will need a pair of subinterface for each VRF interconnection. As simple as that.
Illustration 2: Scenario A
The links between the two Gateways 6VPE are regular VRF interfaces. You have two MPLS-VPN
network side by side. Packet get out from a VRF interface and get in via a VRF interface on the other
6VPE.
2.2 Control Plane
For the Ingress 6VPE the Internal label is the MP-BGP label which has been allocated by the Egress
6VPE MP-BGP, the Gateway A and sent with the IPv6 Route to the Ingress 6VPE.
The external label is following the LSP to the local Gateway A 6VPE /32 loopback address.
Same for Network B the packets received on the VRF subinterfaces have a route to reach the
destination. The next hop is the 6VPE Egress 6VPE Loopback /32 address.
Actually we have two MPLS-VPN side-by-side and a pair of subinterfaces to interconnect each VRF.
2.3 Data plane
The packet leaves the ingress CE as a regular IPv6 Packet.
When the IPv6 packet reaches the Ingress router, it is received by the VRF CEFv6 process. It looks up
the VRF Forwarding Table (FIB). IF it is not there, the packet is dropped and an ICMP6 packet is sent
to the source CE.
if CEFv6 has an entry for this destination it looks up the Adjacency pointer to find the correct
Adjacency in the Adjacency table to find the MAC Address for the next hop found in the FIB table.. If
the MAC address is not present, this triggers the MAC Address resolution with Neighbor Discovery
protocol (NS/NA). In IPv6 a minimum of two packet must be buffered during MAC Address
resolution. This is why ping in IPv6 should always be 100% the first time you reach a particular
destination. IPv4 drops the packet which triggered the MAC Address Resolution and first time we ping
a host we got only 80% success and it is normal.
If the entry is there, label is created and imposed with two levels. The Internal label is the MP-BGP6 to
the GwA which is the next hop of the VRF destination IPv6 Address.
The exernal label it built with IGP/LDP and is most of the time a POP label for a 6VPE.
The POP informs the previous router to remove a label before sending the packet. This way the GwA
only receives the label corresponding to the destination, GwB. So the packet is decapsulated before it is
sent as IPv6 packet to GwB but is switched by the LFIB.
Illustration 3: Scenario A or B. If B the second link can be used for Load-balancing
Then GwB as a regular PE switch the packet to the egress 6VPE which is now the next-hop for the
route.
This Scenario gives maximum control on the data and isolates the networks so there is no MPLS on the
interconnection. MPLS-VPN parameters can be completely different: RD, RT as long as it leads to the
correct egress 6VPE. There are no interaction between the two MPLS-VPN networks and the Network
managers of both companies can choose the RT and RD they want without having to talk with the other
guy of the other network.
3. Scenario B
The Scenario needs two dedicated gateways with an MP-eBGP + Labels session in between. This way
all the vpnv6 routes are exchanged between the two 6VPEs with all the VRF routing info to reach the
destination.
First we must disable the automatic dropping of all the paths which are not imported by any VRF. We
are not going to configure any VRF on the Gateways.
“no default BGP routetarget filter” command within the BGP address-family vpnv6
configuration. A Next hop self command is recommended so the local 6VPE see their Gw as the
next hop. Otherwise the 6VPEs must have a route to the neighbor Gateway.
With this method we advertise all the paths. Also, it requires two big dedicated routers.
A Big difference with the previous, we have MPLS running between the two gateways instead of IPv6.
As we use multihop MP-eBGP+Labels between the Gateways to carry all the vpnv6 table, the next-hop
for the inter VRF communication will be the advertising Gateway itself. The neighbor nexthop self configuration command is needed for Gateway A to be the next hop for any destination going to
SP B.
The packet can cross the link between Gateway A and Gateway B thanks to a route and a label
advertised by a MP-eBGP vpnv6 multihop.
When Gateway B receives the packet it has the two labels needed to encapsulate the packet to the
egress 6VPE. The External label are given by LDP or RSVP to reach the Egress 6VPE and the internal
label that was allocated and advertised by the Egress 6VPE.
This solution does not allow the same granularity of control as previous but is much more scalable if
you have two big networks to interconnect for the same customer. In this scenario the VRF parameters:
RD and RT must be consistents as BGP is not stopped anywhere and the 6VPE vpnv6 paths with RD
and RT are advertised from one side to the other.
This is a good solution if one of the 2 networks don't use BGP Route Reflector otherwise prefer
solution C.
Illustration 4: Scenario B
4. Scenario C
In this Scenario we use the Route Refelector which have all the vpnv6 routes to interconnect the two
networks. We save the two big Gateways of Scenario B. As the route to the destination next-hop is the
egress 6VPE loopback address, the ingress 6VPE must have a route and a label to the Egress 6VPE in
the other Service Provider Network! That's why this is mostly used when the two backbones belong to
the same Company
In this solution we interconnect the Route-Reflectors of the two MSPL-VPN networks so all the vpnv6
routes will be learned with a Multihop MP-eBGP session between the RR.
As we connect the two RRs of the two MSPL-VPN Networks, they have different AS. eBGP changes
the Next-Hop of the route it advertises to itself. So if we don't do anything the routes will be advertized
with the RR as the Next-Hop then packet will be dropped because they will don't know how to reach
the egress 6VPE from the RR so the next hop should not be changed by the BGP Route Reflectors.
Hopefully we have a BGP command to tell BGP not to change the next hop which remains the
advertising 6VPE Loopback /32 address. The Next-hop of the 6VPE will be the /32 IPv4 addresses
which must be leaked into the other network.
Between the two gateways we need to configure ipv4 routing for SP A to know a route and a label for
each 6VPE loopback address and the opposite as well. eBGPv4 + Label can be used to leak the 6VPE
loopback addresses to the other SP.
In this Scenario the initial MPLS packet has the Egress 6VPE label and not Gateway A. So the Nexthop for the ingress 6VPE will be the Egress 6VPE loopback /32 address, that's why we need LSP
between all 6VPEs of both Service Providers. Each SP must know a route and a label for each remote
6VPE Loopback.
Illustration 5: Scenario C
Scenario is really the most effective to merge two networks of the same company.

Download Report