Current architecture has us using MPLS - 25 stub branches which communicate back to 2 our Corp centers. 50% route to Corp 1, the other 50% route to Corp 2.
Has anybody had any experience with such a project? We are currently running EIGRP which we can continue to use but I'm still trying to figure out the BGP setup. We have some route maps which are being used for the branch routing but I'm assuming this will not be used at the layer 2 level?
I suppose you are considering to migrate the two central offices and the 25 branch offices from an MPLS L3 VPN service where you are using eBGP as PE-CE protocol to a VPLS solution where you will be able to run directly EIGRP between your routers.
IF this is the case the BGP process and the route-maps for redistribution between BGP and EIGRP that you have now on your branch routers will not be needed anymore.
However, it is important to define how the migration will be performed.
Likely you will have a different ethernet handoff for the L2 service (at least a different Vlan subinterface).
You can enable EIGRP over the new FLAT network and then you can migrate one branch site to make a pilot test.
With default settings and both the MPLS L3 VPN active and the new VPLS service active the branch site will still prefer the eBGP routes over the EIGRP routes, the same will happen on the central site routers.
You can verify that EIGRP neighborships are formed over new L2 service and you can check the EIGRP topology table to see you are receiving EIGRP updates.
Then you can increase the BGP admin distance for eBGP routes to 180 in router bgp process on both the remote site and the central site to see the EIGRP routes installed.
The distance (BGP) command should accept three values for eBGP, iBGP and locally generated routes respectively default values are 20, 200, 200.
On central site routers you can consider using a distance command with access-lists to selectively increase AD only for prefixes of the remote pilot site.
Hope to help
Can you provide some more information about your current environment and what you will transition to? MPLS typically visibly has an ISP sitting between the core/hub/HQ and the remote branches which are treated as far away. Switched Ethernet typically makes everything look like it is locally connected and does not typically have an ISP sitting in the middle.
Your post mentions BGP and also talks about EIGRP. It is not clear what protocol is used where and not clear what the intention is for the new environment. In my experience with networks using switched Ethernet it is common to use EIGRP as the corporate routing protocol (and also OSPF). I am not familiar with a corporate network using switched Ethernet that uses BGP.
In the new environment will the switched Ethernet provide a single broadcast domain/common IP subnet for all branches and 2 HQ? Or will it provide a separate vlan (separate IP subnet) for each branch?
Current setup has a fiber hand off at each location. Yes we are using ATT's MPLS architecture for connectivity. The new design which would essentially be one logical switch as you suggested - as for whether it one single broadcast domain or not I don't know, I was assuming it was going to one single domain.
We use BGP externally to connect to remote branches and EIGRP internally between to CORP centers. EIGRP routes are selectivity advertised and controlled at these 2 head end routers(3945's) by lowering AD to 11, this way they are advertised into BGP.
I do not fully understand your comments about BGP. And that probably does not matter since I do not see BGP operating in your new switched Ethernet environment.
You comment that EIGRP routes are selectively advertised and mentioned route maps used in the current environment. Whether you can continue to do this may depend on the answer to the question that I asked about a single broadcast domain. If your new environment will be a single broadcast domain then I do not see how you can be selective about advertisement. In that case when a branch router sends an advertisement it will be received by both core routers and also received by every branch router. And when a core router sends out an advertisement it will be received by every branch and the other core. So in that environment every router will know every route. This environment would facilitate branch to branch communication since they would know about each others resources and be able to communicate directly without needing to go through the core. Whether that is good or not depends on your perspective.
If your new switched Ethernet is not a single broadcast domain then there is probably a vlan per branch (probably using QinQ or some similar technology) and communication from a branch must go through the core to get to other branches and to get outside. This would allow the core to selectively advertise to each branch.
as suggested by Rick if you have a port based VPLS service you can make use of a single 802.1Q Vlan tag to create multiple broadcast domains in order to get better control on how connectivity and routing is performed.
Given the low number of branch routers if a dedicated port for the new VPLS service is available on each router you can even replicate the current scenario with half devices preferring one central office router and one half of remote routers preferring the other central office router.
For doing this two broadcast domains would be enough and just playing with delay setting you can create the desired hierarchy of paths.
In each broadcast domain you would have only one central site router (or you can modify delay also on the cental site subinterfaces).
Each remote site will prefer the subinterface with default delay settings over the one with modified increased delay.
For a customer we built a VPLS "port based" able to support "plug and play" tagged Vlans between Vlan 1 to Vlan 4094.
The customer is an university and they wanted to act as a metro ethernet service provider for departments.
Two or mode departments could build a L2 broadcast domain asking to the university stuff a Vlan id to use.
We had to create a separate VPLS for untagged frames over the same access interfaces and it worked covering all possible cases with only two VPLS.
Hope to help