Full Mesh:- Achieves full redundancy between all the sites.
Hub and Spoke:- HQ and branch office scenarios
Extranet:- Share resources between the different customer sites or share resources between the customers and the suppliers.
Overlapping:- Typically used to access common resources like Firewalls or other servers
In the case of full mesh every site has a connection to the other sites.
The route distinguisher between the PE and the CE routers should be same and the import and the export route targets should be same.
In this design scalability issues might arise if the number of PE's is substantially large.
Route reflectors in VPRN:-
Here it is not mandatory to have a full mesh of ibgp sessions.
With RR's the PE forms adjacency only with the RR's and not with all the PE's
Hub and Spoke:-
The client sites requires direct connection to the HQ office but the client sites does not require connection with each other.
This design offers less redundancy and loss of a router will lead to loss of some services but the benefit is manifold as it reduces cost.
In this case the number of VPN tunnels are reduced, filtering or any policy can only be applied to the hub site.
The downside is spoke sites can only send and receive traffic through the hub site.
Spoke to spoke is possible but it should be passing through the hub site.
The rules that are followed are:-
Given below is what it will happen the export route targets for all the spoke sites will be impoerted by the hub site while the export route target for the hub site will be imported by the spoke sites.
CE Hub and Spoke:-
In this case traffic from the remote sites passes through the central CE site.
This is generally useful if there is a firewall on the central CE site and all the traffic should pass through that device then this design should be beneficial.
In this case the following rules are applicable:-
The CE hub site should learn all the routes from the spoke site
The spoke site should not communicate directly with another spoke site but should do it through the CE hub site only.The spoke sites should not learn of routes from other spoke sites.
Overlapping VPRN:-
PE2 and PE3 advertise the routes received from the hub toVRF-10 advertises its routes via MP-BGP to PE2 and PE3 nexthopHub CE-1 advertises the routes to VRF-10 in PE1 next-hop CE1.The hub PE advertises the spoke routes to the hub CE1.The spoke PEs advertise the spoke routes to the hub PE VRF-1The spoke CEs advertise their routes to their respective PEs
Hub and Spoke:- HQ and branch office scenarios
Extranet:- Share resources between the different customer sites or share resources between the customers and the suppliers.
Overlapping:- Typically used to access common resources like Firewalls or other servers
In the case of full mesh every site has a connection to the other sites.
The route distinguisher between the PE and the CE routers should be same and the import and the export route targets should be same.
In this design scalability issues might arise if the number of PE's is substantially large.
Route reflectors in VPRN:-
Here it is not mandatory to have a full mesh of ibgp sessions.
With RR's the PE forms adjacency only with the RR's and not with all the PE's
Classical iBGP split horizon rules mandate that updates
received on eBGP sessions should be forwarded to all iBGP and eBGP sessions, but updates
received on an iBGP session should be forwarded only to all eBGP sessions. This requires the BGP
edge router to send updates to all other BGP-enabled routers in its own AS directly through individual
iBGP sessions to each BGP router.
RRs modify the iBGP split horizon rule and allow a specific router,
under certain conditions, to forward all incoming iBGP updates to an outgoing iBGP session. This
router is called a route-reflector.
In the absence of RRs, whenever a new PE is introduced, every existing PE in the service provider
network will require an additional BGP neighbor command associating it with the new PE. In BGP,
updates received by a peer in an AS are not allowed to be forwarded to another peer within the same
AS. Therefore, a BGP network must be fully meshed, with all peers adjacent to one another, as far as
BGP routing updates are concerned. If the number of PEs becomes substantial enough to make this
operation impractical, BGP RRs are recommended. RRs avert the need to fully mesh the BGP peers
and avoid adding neighbor commands to each PE. With RRs, the PEs would only require neighbors
defined for each RR. Any updates, including VRF information, would be sent to the RR alone. The
RRs are then responsible for propagating information received from PEs to all the other PEs.
RRs are also useful in the event of a route change in the customer network. Without RRs, the PE that
locally terminates the portion of the customer network would have to update every PE peer
participating in that VPN. RRs, therefore, help remove the burden of BGP updates from the PE.Hub and Spoke:-
The client sites requires direct connection to the HQ office but the client sites does not require connection with each other.
This design offers less redundancy and loss of a router will lead to loss of some services but the benefit is manifold as it reduces cost.
In this case the number of VPN tunnels are reduced, filtering or any policy can only be applied to the hub site.
The downside is spoke sites can only send and receive traffic through the hub site.
Spoke to spoke is possible but it should be passing through the hub site.
The rules that are followed are:-
The policies that are required to implement this topology are outlined
below. Any access not specifically mentioned is not to be permitted.
The hub site PE should learn all of the routes from the spoke sites.
The spoke sites should only learn routes from the hub site. 
Given below is what it will happen the export route targets for all the spoke sites will be impoerted by the hub site while the export route target for the hub site will be imported by the spoke sites.
CE Hub and Spoke:-
In this case traffic from the remote sites passes through the central CE site.
This is generally useful if there is a firewall on the central CE site and all the traffic should pass through that device then this design should be beneficial.
when traffic between a pair of sites needs to be passed through a firewall device that is
located at the customer site, the CE hub and spoke design can be used. If CE-1 will be used as the CE
hub site, then there will be two connections (either physical or logical) required between CE-1 and PE-1.
This design allows the hub CE to filter or monitor the traffic that is being sent from spoke-to-spoke sites.
Any access not specifically mentioned is not to be permitted.
• Permit access between all CE devices, all sites participating in the same VRF, with the CE-1 as
the hub device.
• Traffic between spoke sites must go through the hub CE. The hub CE may or may not allow
traffic to traverse from one spoke site to another based on the policy configured on the hub CE.In this case the following rules are applicable:-
The CE hub site should learn all the routes from the spoke site
The spoke site should not communicate directly with another spoke site but should do it through the CE hub site only.The spoke sites should not learn of routes from other spoke sites.
All spoke-to-spoke traffic must go through the Hub CE1
and next-hop the appropriate CE.
and next-hop to the appropriate spoke PE.
PE1.
their respective CEs.
VRF1 uses 65100:1 and vrf 10 uses 65100:10, since a sap interface can be associated with 1 vrf interface there are two physical or two logical interfaces required and 2 vprn 's should be configured.
VRF 1 in the hub sites should import the route targets from the 3 sites.
VRF 10 should export a router target, which should be imported by VRF1 on the spoke sites.
Extranet Application:-
In this case the two locations of two different companies share the routes probably only the head offices and not the branch offices.
The Customer Blue VPN consists of CE-1 and CE-2. These sites use a route target shared
between only themselves. In the example in the slide, route target 65100:1 is used.
• The Customer Red VPN consists of CE-3 and CE-4. These sites use a route target shared
between only themselves. In the example in the slide, route target 65100:2 is used.
• The overlapping VPN consists of CE-1 and CE-3. These sites use a route target shared between
only themselves. In the example in the slide, route target 65100:3 is used. These sites also
participate in their respective Blue and Red Intranet VPRN.Overlapping VPRN:-
In an overlapping VPRN, the following rules should be maintained:
The customer VRFs participating in the overlapping VPRN contain the server routes and routes from
the same customer VPRN, but do not contain routes from other customers.
The customer VRFs not participating in the overlapping VPRN only contains routes from the same
customer VPRN.
The server VRFs contain the server routes and the customer routes.
This topology limits network access to the following policy based on the diagram shown in the slide. Any
access not specifically mentioned is not to be permitted.
Permit access between CE-1 and CE-2
Permit access between CE-3 and CE-4
Permit access between CE-5 and CE-1
Permit access between CE-5 and CE-3
The Customer Blue VPN consists of CE-1 and CE-2. These sites use a route target shared
between only themselves. In the example above, route target 65100:1 is used.
• The Customer Red VPN consists of CE-3 and CE-4. These sites use a route target shared
between only themselves. In the example above, route target 65100:2 is used.
• The Overlapping VPN consists of CE-1 and CE-5 and CE-3 and CE-5. These sites use a route
target shared between only themselves. In the example in the slide, route target 65100:5 is used.
