Hello Vishal,
there are some notes that may be useful about your design and the different topology options.
We see that design option 1 has the cross -over direct links between WAN router CEi and Core switch j with i <> j, design 2 misses this cross-over direct links.
Design option 1 provides link redundancy in the EIGRP routing domain and fault tolerance to single link fault for these addtional links.
Design option 2 can be improved if EIGRP is activated on the CE1 to CE2 direct link. If this is done the EIGRP domain achieves redundancy and fault tolerance to single link fault. So this is the first suggestion.
Looking at the whole routing plane we can see that design option 1 has still an advantage over design option 2: it allows true load balancing from the point of view of a single core switch in reaching the remote site IP subnets. It is enough that the two CE routers redistribute BGP routes into EIGRP with the same seed metric to achieve. Until both CE routers advertise the same IP subnet with the same seed metric each core router sees two equal cost paths one via CE1 and MPLS SP1 and one via CE2 and MPLS SP2.
This load balancing over both MPLS clouds cannot be achieved by design option 2 even with EIGRP enabled on CE-toCE link as each core router will prefer the directly connected CE router for the way EIGRP metric works also for external EIGRP routes.
In order to achieve load balancing over both MPLS clouds the core switch should support GLBP on client facing Vlans. This would lead to some clients using core switch 1 as default gateway and other to use core switch2.
GLBP may be supported or not on the core switch multilayer switches.
So if the design objective is to use both MPLS clouds in load sharing and GLBP cannot be used, design option 1 is to be preferred, but the direct link CE to CE might be removed under certain conditions.
More on this later.
Let's see if the complexity of the solution in the routing plane can be reduced.
Redistribution of BGP into EIGRP is needed unless a full mesh iBGP is built between CE1, CE2, core switch1, core switch2. So we consider this a needed part.
My understanding from your notes is that you are performing mutual redistribution, that is you are also redistributing EIGRP into BGP.
>> Tagging and Route-maps will be used while redistibuting from BGP to EIGRP to stop propagation of these routes again to BGP cloud.
If the number of EIGRP routes is not high < 200 EIGRP routes can be injected in BGP by simply using the network command under router bgp and this is a great simplification as it removes the need for mutual redistribution.
So the second suggestion is to consider the use of the BGP network command instead of redistribution of EIGRP into BGP in the smaller sites that have not so many local routes.
The last point to discuss is the role of the iBGP session between CE routers.
Each CE router connects to a different MPLS SP cloud. If all sites are multihomed to both MPLS SP1 and MPLS SP2 different strategies are possible:
a) total separation between the two clouds-
the iBGP session is not needed at all in this case each SP cloud is stand alone if one remote site link to SP1 fails the remote site IP subnets will be reachable via SP2 and CE1 will stop to inject the routes into EIGRP in the local site.
The design is still fault tolerant to a single link or node fault, load balancing may be performed in normal conditions.
This is a good choice for remote sites.
b) interconnection between the two VPNs in central site and/or selected sites-
In this case the iBGP session provides a backup path via SP2 to those remote sites that are only connected to SP1.
The event that can be covered with this design is site K only connected to SP1 to be able to communicate to site M only connected to SP2. This is a double fault that might happen.
The iBGP session on central site and/or remote site can cover this case by propagating routes between SP1 and SP2 via the CE routers of central site /selected sites.
So in my opinion the iBGP session is useful only when you want to implement strategy b).
And this leads again to the fact the direct link between CE routers may be removed saving the addition of a network module.
>> AS path access-list allowing only local AS routes to BGP (Do I still need this if I am using tags in BGP - EIGRP Redist.?
Until you have the iBGP session if you want to keep the two clouds separated (strategy a) you need the AS path filtering, because the iBGP session provides the leakage on the routing plane between SP1 and SP2 clouds.
The route-maps with tags applies only to redistribution of EIGRP into BGP and does not provide filtering on BGP routes passed to an eBGP peer
The AS path filtering should be removed or modified to allow route propagation between SP1 and SP2 clouds.
However, if the choice is this one (strategy b) it can be implemented only on central site or selected sites is not needed in all sites to save on complexity.
Hope to help
Giuseppe
