This is kind of a complex question, as the two different products are very different. A MPLS L3VPN circuit inherently is a full mesh between all locations that participate, while a MetroE connection is generally a point to point link between two specific sites.
In my experience, a MetroE circuit is a directly provisioned path, with no protect services, unless contracted with a protect path. This means that failure of an interface or router along the specific path would be traffic interrupting between the two sites that are directly linked by the MetroE service. The MPLS L3VPN will heal around interface/routing failures to keep you with a full mesh between your sites. This generally accounts for the price difference between the two.
There is nothing wrong with building your own services on top of a MetroE platform -- you just need to work with customer requirements to determine what type of routing is appropriate. If you are working with a small office network, OSPF/IS-IS/EIGRP could be a wonderful way to exchange routing information between the directly connected sites that you have established. If you're more of an NSP/ISP/*SP, separating infrastructure and customer routes between IGP and EGP becomes much more important as you scale.
As an ISP engineer, we extensively use MetroE and EWAN links to build our backbone, and utilize our knowledge of the physical links to design our iBGP/eBGP environment. In many cases, we use route reflectors, and dual route reflectors (route-reflector-client on both sides of the peering) to reduce our iBGP peer count. However, unless you're dealing with 6+ routers in a POP, iBGP scales pretty well.
In short -- if it's for a single client, that is not offering network services to clients of their own -- stick with an IGP. If external connectivity needs to be shared between sites, with failover/redundancy/etc, closely examine the physical paths you have, and design your eBGP/iBGP to reflect that. No point in having a router in a remote location with only 1 link outside the site to iBGP peer with all other routers in the AS -- use a dual route reflector.
Well, this is kinda funny. Firstly, I should mention that this is a project that I was recently asked to work on where everyone that previously worked on it has left the company and there is next to no documentation. All I had to go on was a grossly inaccurate network topology diagram which I am in the process of redrawing.
Anyway, after investigating a million other things, I traced the tremendous mess of cables behind the server racks to look at the multiple ethernet cables from the segment that wasn't talking to the rest of the network. This is where I saw no link lights for the ethernet ports on the back of a server whereas the front panel showed several green lights. What I found out is that the front panel of the server will show those green lights even when it isn't turned on! Since it was off, there was no active connection from that particular server rack to the rest of the network. After turning it on, I checked the router again and AREA 0 is no longer inactive. It now has its OSPF neighbors and routes that it should have and the end devices are able to communicate properly. So, everything works now that the server has been turned on.
In summary, one needs to always ask the following two questions:
- Are you sure it's plugged in?
- Have you tried turning it off and on again?
Best Answer
What does the topology look like? How are you doing routing today towards these networks? Or is the router being deployed now? Do you have an OSPF capable router connected to this router that is not running OSPF?
If you do then I suggest you redistribute static on this router. Something like:
The explicit deny at the end is not really needed as there is an implicit deny but it makes the logic a bit more clear.
Then under the OSPF process: