The selection of the LAST MILE Protocol between PE-CE depends upon the Customer Requirement & the Feature Support of CE itself.
BGP will ensure the easy Management of Network in an ISP perspective. In addtion, take a call with the Customer and identify the IGP Protocol used in the Customer Network and the Customer Requirement for the LAST MILE Protocol. Becacuse the LAST MILE Protocol used and the IGP of the Customer are to be Synchronized.
The final choice of the IGP to use in a private MPLS should take into consideration the convergence time for each one of them and scalability of the design.
For example, taking the two routing protocols that you mention: OSPF and EIGRP.
In a standard networking environment OS I don't remember any caveat with PF will be a very good choice since it integrates with third parties, has the concept of Areas, force certain level of hierarchical model in the deployments, etc. On the other hand, EIGRP has a much faster convergence time, is very simple and have some concepts, like stub, which may help scaling it somehow.
Now, when you put MPLS into the equation, the first thing to know is that OSPF, from the MPLS provider perspective, consume too much resources and does not scale for hundreds of customers. This is because you will have to define an OSPF process on per-customer, etc. The maximum amount of OSPF process varies on pre-platform basis. (In your case, since it may be the same "customer" this might not be an issue).
From the customer perspective, OSPF does not behave the same way as the regular OSPF. For example, you can not have a device in Area 0 and the serve as ABR, for another Area, over the MPLS clouds. This is because the summary routes, among others, are not going to be advertised by the vpnv4 BGP.
Another issue is when an area have back door links and peerings. This may introduce suboptimal routing, and so on.
Now, on EIGRP, from the MPLS provider, it may be a single EIGRP process since it has the "address-family" concept. From the customer perspective, it is just another regular peering. If back door links and peerings exist, you may still need to work with subobtimal routing. Besides these, I don't remember any other caveat with it.
No matter which protocol you may choose, make sure you understand any caveat that may exist. In L3 VPN, from the customer perspective, it may "look like" regular routing, but it is not, and protocols like OSPF, does have some strict implementation requirements.
EIGRP or OSPF - what is the customer happier with and what does the customer understand OPS wise? From an SP point of view - what are they willing to offer? You may find they are willing to offer neither of these protocols and only offer bgp and static as the CE-PE protocol.
Issues surrounding both protocols.
EIGRP - if you have loops i.e. CE1 connected to CE2 then you connect CE1 to PE1 and CE2 to PE2 you encounter a loop. This is mitigated by using EIGRP-SOO. This configuration is new to both SPs and your customer. This may scare them. The same i may add is required for BGP depending on configurations.
Same scenario as above except this time CE1 and CE2 are in different buildings connected via a 64k link. CE1 connects to PE1 as Gig. CE2 connects to PE2 as gig. CE1 and CE2 are in OSPF area 1. The traffic from CE1 to CE2 goes via the 64k link ALL the time. Why??? OSPF in an mpls environment tags all routes as IA routes. So IF CE1 had 184.108.40.206 network on it PE2 would advertise this network to CE2 as IA 220.127.116.11 However CE1 would advertise the same route to CE2 over the 64k link as an O route - hence it is therefore preferred.
To get round this issue the SP has to configure things called "sham-links". This is the main reason why SPs dont offer OSPF as their OPS people get really confused when fault finding with sham links in the way. Scaling of OSPF is now really not an issue as the limitation of 28 processes in total on a PE is negated by bigger memory now.
Reading through your posts it seems that you are trying to deploy MPLS within a Corporate environment. EIGRP will work just fine as the Core routing protocol in this case however please note the following limitations that I can think of
- Vendor proprietary (Cisco)
- No TE capabilities if this is a requirement
I will make some basic assumptions with regards to your topology. I presume that you are looking to separate BU's from each other into separate VRF's. You can run LDP and EIGRP on your Core Devices (termed as P devices) however between your PE devices (the devices configured with VRF's) you will be running BGP VPNv4.
I would however go with OSPF as the Core Routing protocol since it does offer TE capabilities and is not vendor dependent. I would have gone with IS-IS however it would really depend on the knowledge base available to you. HTH
1. Introduction Internet security is important with the increasing
attacks that are happening every day. Many internet and browsing
security solutions exist, but some are not very easy to use or maybe the
question is how can I enable them? In this referen...
Cisco Software Manager Server API Guide This document describes the
programmatic interfaces, RESTful APIs, which are supported by Cisco
Software Manager Server (CSM Server). Overview CSM Server supports a set
of finite RESTful APIs. The first step to use ...
If you are using Cisco's new linux-based Cisco Software Manager server,
then you probably want to make sure there is a startup service for
it.I'll assume that you've already installed the CSM server on a
systemd-based linux system. The commands given belo...