Hi Ryan, I did some work for a customer a few years back doing something very similar.
Campus network, 2x 6500s as P routers, 12x 6500s running as PEs, each connected to both Ps. Access switches then connected directly to the PEs. The SVIs were hosted on the 6500 PEs. We use VSS for DCs where we had dual 6500s rather than running HSRP/VRRP. Worked really well, and was very simple to debug and configure. The only concern is that spanning tree issues would propagate to the 6500 PEs, however thankfully, they seemed to have enough CPU/ protection to not have a problem with this. I have since worked on another campus network, where the buildings had dual CEs installed. Access switches were directly connected to the CEs, and HSRP/VRRP was used to failover the access switches between the CEs. The CEs had multiple VLANs to the PEs, one for each VRF/VRFLite (and a BGP session for each VRF/Lite on each VLAN). This also worked, but was a lot more difficult to debug and maintain. Adding a new VRF involved a lot of changes on a lot of devices. In both cases I would recommend using scripts to configure your devices to ensure consistency, however in the first option you could possibly get away without. The second method, using CEs, will be very very error prone without automatic configuration. -- Andrew On Wed, Nov 30, 2016 at 11:14 AM, Ryan L <ryan.nspl...@gmail.com> wrote: > Hey all, > > Apologies if this is a muppet question, but still getting my bearings with > MPLS. Most L3VPN designs I've checked out don't really address this > specific design... > > I've got a multi-tenant network that would either be done w/VRF-lite or > L3VPN, but I don't have a CE router, per se. > > Is it somewhat accepted design to run L3VPN in a scenario where the PEs in > DC1 are vrrp active/standby for DC1 VLANs in all VRFs, and the PEs in DC2 > are active/standby for DC2 VLANs in all VRFs, and so on? From each PE, > there'd be a layer 2 path to the edge hosts within those sites, and we're > talking pure routing here, no state tracking devices, etc. PEs would be > meshed iBGP either full or w/RRs. > > Not sure if there are some limitations/major issues I'm overlooking here, > but seems much cleaner than trying to stitch vrf-lite everywhere. > > Thank you. > _______________________________________________ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/