Multi-As Vpn - 3Com S7906E Configuration Manual

Routing information exchange from the ingress PE to the egress PE
After learning the VPN routing information from the CE, the ingress PE adds RDs and VPN targets for
these standard IPv4 routes to form VPN-IPv4 routes, and maintains them for the VPN instance created
for the CE.
Then, the ingress PE advertises the VPN-IPv4 routes to the egress PE through MP-BGP.
Finally, the egress PE compares the export target attribute of the VPN-IPv4 routes with the import target
attribute that it maintains for the VPN instance and determines whether to add the routes to the routing
table of the VPN instance.
PEs use IGP to ensure the connectivity between them.
Routing information exchange from the egress PE to the remote CE
A remote CE can learn VPN routes from the egress PE in a number of ways. The routes can be static
routes, RIP routes, OSPF routes, IS-IS routes, or EBGP routes. The exchange of routing information
between the egress PE and the remote CE is the same as that between the local CE and the ingress
PE.

Multi-AS VPN

In some networking scenarios, multiple sites of a VPN may be connected to multiple ISPs in different
ASs, or to multiple ASs of an ISP. Such an application is called multi-AS VPN.
RFC 2547bis presents three inter-provider VPN solutions:
VRF-to-VRF: ASBRs manage VPN routes between them through subinterfaces. This solution is
also called inter-provider VPN option A.
EBGP advertisement of labeled VPN-IPv4 routes: ASBRs advertise labeled VPN-IPv4 routes to
each other through MP-EBGP. This solution is also called inter-provider VPN option B.
Multi-hop EBGP advertisement of labeled VPN-IPv4 routes: PEs advertise labeled VPN-IPv4
routes to each other through MP-EBGP. This solution is also called inter-provider VPN option C.
The following describes these three solutions.
Inter-provider VPN option A
In this kind of solution, PEs of two ASs are directly connected and each PE is also the ASBR of its AS.
The PEs acting as ASBRs are connected through multiple subinterfaces. Each of them treats the other
as a CE of its own and advertises IPv4 routes through conventional EBGP. Within an AS, packets are
forwarded using two-level label forwarding as VPN packets. Between ASBRs, conventional IP
forwarding is used.
Ideally, each inter-provider VPN has a pair of subinterfaces to exchange VPN routing information.
1-9