Reading through the well-written CCDE Study Guide book by Marwan Al-shawi, came to a section about having BGP as the Enterprise Core Routing Protocol and its possible Design models.
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.
This post contains my notes from an old version of IPX Class on Demand by Joe Astorino.
RD has no special meaning—it is only used to make potentially overlapping IPv4 addresses globally unique
Route Targets are additional attributes attached to VPNv4 BGP routes to indicate VPN membership
Export Route Targets identifying VPN membership are appended to customer route when it is converted into VPNv4 route
RD & RT are extended BGP communities; neighbor send-community extended is required!
RR for VPNv4 does not need to be the same as RR of IPv4.
PE imposes 2 labels, the one if from LDP, and the bottom one is from VPNv4 address-family.
Each bgp address-family is a different RIB.
Import policy means that routes will come from the VPN extended community
Export policy means that routes will go to the VPN extended community
ARF –Automatic Route Filtering: Only VPN information matching a locally configured RT will be imported Could be disabled: no default bgproute-target filter
By default, when running OSPF over Frame-Relay and network type is anything except point-to-multipoint, on a spoke, the nexthop for a route originated from another spoke will be that spoke. But when the network type is point-to-multipoint, the nexthop will be the hub, and a host route for each spoke will exist. So make sure to use point-to-multipoint when using MPLS.
RIP/EIGRP address-family version and summarization is different form the RIP/EIGRP’s itself.
When the customer needs the same AS on multiple sites, the AS Override feature should be triggered. So the PE will override its (prepend). Another way to handle this requirement is using allowas-in.Continue reading “IPExpert CoD: MPLS-VPN”
Most popular were Frame Relay or ATM technologies, providing VPN service at Layer 2. The provider had a Frame Relay or ATM backbone and supplied Layer 2 connectivity to the customer routers. This was commonly referred to as the overlay model.
The service provider might have actually owned or managed the edge routers that were connected to the customer network. The point is that the routers were physically at the customer premises.
Peer-to-peer VPN networks existed, but they were not popular. The main reason is that they were not easy to deploy and maintain because they needed distribute lists, IP packet filters, or GRE tunnels. As explained in Chapter 1, MPLS VPN is an example of a highly scalable peer-to-peer VPN model.
The CE router does not peer with any of the CE routers from the other sites across the service provider network, as with the overlay model. The name peer-to-peer model is derived from the fact that the CE and PE form a peer at Layer 3.
Virtual routing/forwarding (VRF): is a VPN routing and forwarding instance. It is the name for the combination of the VPN routing table, the VRF Cisco Express Forwarding (CEF) table, and the associated IP routing protocols on the PE router.