User Manual

81-32
In the above figure, Spoke sites communicate with each other via Hub sites (the arrow in the figure is the
route advertisement process from site2 to site1):
 Hub-PE can receive VPN-IPv4 routes advertised by all Spoke-PE
 The VPN-IPv4 routes advertised by Hub-PE can be received by all Spoke-PE;
 Since Hub-PE can advertise routes it learns from Spoke-PE to other Spoke-PE, the spoke sites can
intercommunicate with each other via the Hub site.
 The Import Target attribute of any Spoke-PE is different from the Export Target attribute of other
Spoke-PE. So, any pair of Spoke-PE cannot advertise VPN-IPv4 routes to each other or
intercommunicate directly.
Extranet VPN
Figure 81-6 Extranet Networking Resolution
If a VPN user wants to provide some site resource of this VPN to outside users, the Extranet Networking
resolution can solve the problem.
In this networking if a VPN needs to access the sharing site, its Export Target should be included in the Import
Target of the sharing site VPN instances, and its Import Target should be included in the Export Target of the
sharing site VPN instances.
In the above figure, site3 of VPN1 can be accessed by VPN1 and VPN2:
 PE3 can receive the VPN-IPv4 routes advertised by PE1 and PE2
 PE1 and PE2 can receive the VPN-IPv4 routes advertised by PE3
 Based on the above two conditions, site1 and site3 of VPN1 can intercommunicate, so do the site2
of VPN2 and site3 of VPN1.
PE3 won’t advertise VPN-IPv4 routes from PE1 to PE2, or advertise the VPN-IPv4 route from PE2 to PE1 (the
routes learnt from an IGBP neighbor won’t be sent to other IBGP neighbors), so site1 of VPN1 and site2 of
VPN2 can’t intercommunicate.
site2
VPN1
PE3
VPN2
CE
site1
CE
PE1
VPN1:
Import: 1:1
Export: 1:1
PE2
VPN2:
Import: 2:1
Export: 2:1
VPN1:
Import: 1:1, 2:1
Export: 1:1, 2;1
VPN1
site3
CE