To make it a little bit brighter to myself, I’m gonna explain them in a different way with different diagrams and matrix based on my own design experience with these models.
Disclaimer: Please have in mind that the number of routers drawn, doesn’t reflect the reality of the design, and is just been this way for the sake of simplicity; obviously there would be redundant routers in real World, and also the Core could span different PoPs.
Besides, the bigger border routers could reflect two separate ones, one on Core, and one on Branch side.
Design Model 1
This model is suitable when least Administrative Domain Control is required; though it still overcomes an end-to-end IGP design, providing better management between remote campuses.
Core IGP is mainly used to provide Next-hop reachability for iBGP speakers. Please note that this is applicable to all models where iBGP is used in the Core.
The downside to this design is moderate operation complexity; which could arise i.e. by IGP-into-BGP Redistribution and iBGP full-mesh/RR/Confederation management in the Core.
Design Model 2
In this model, each Site has its own ASn to peer with the Core.
This model offers low complexity and moderate Administrative Domain Control to global enterprise WANs.
Same as Core IGP, the Branch IGP is mainly used to provide NHP reachability for iBGP speakers.
Design Model 3
This model utilizes MP-BGP, thus it’s safe to call it MPLS L3VPN design model. From my understanding, this model offers different possibilities for the routing taste.
This model offers the highest Administrative Domain Control between the sites, additionally with end-to-end path isolation, which makes it an incredible choice for global enterprise networks under multiple Administration domains.
Moreover, it’s more than flexible to integrate new capabilities (such as multicast, IPv6, etc.), whether across specific domains or the whole network.
Unfortunately, this model brings high operational complexity!
CCDE Study Guide book combines all the possibilities of this model, but I’d rather at least have a separate diagram for each:
Following the design policies in this model, each branch may have its own ASn.
Design Model 4
This model focuses on eBGP peering in the Core, providing high Administrative Domain Control with less operational complexity comparing to Model 3. This happens by direct eBGP neighboring between all the Branches (Full-mesh eBGP).
An interesting use-case for this model is when different environments or scenarios have to be merged, or when two global companies are integrating into each other.
Each site has its own ASn, and the Branch IGP could be used not only for local domain reachability, but also next-hop reachability to BGP speakers.
From my point of view, this model can be implemented in two approaches:
To sum it up, I gathered the main elements of each model in the matrix below:
|1||iBGP (IGP)||iBGP+IGP||IGP||Core IGP is mainly used to provide NHP reachability for iBGP speakers.|
|2||iBGP (IGP)||iBGP+eBGP||iBGP (IGP)||Core and Branch IGP is mainly used to provide NHP reachability for iBGP speakers.|
|3.1||MP-iBGP||iBGP+eBGP||iBGP (IGP)||Core and Branch IGP is mainly used to provide NHP reachability for iBGP speakers.
Each Branch may have its own ASn.
|3.2||MP-iBGP||iBGP||iBGP (IGP)||Branch IGP is mainly used to provide NHP reachability for iBGP speakers.|
|4.1||eBGP||eBGP||iBGP (IGP)||Full-mesh eBGP!
IGP may be used inside Branch to provide local and NHP reachability for BGP speakers. There’s direct eBGP peering between all branches.