That's what we currently do, however the problem is that we have other routers and firewalls in our network which are only running OSPF, and they need to know about the routes which pass through the eBGP network, Since those routes would become OSPF external, they would only be used if the internal routes went away.
On Wed, Jan 13, 2010 at 3:34 PM, Saxon Jones <[email protected]> wrote: > If I understand your question properly, why not just change the > administrative distance of the eBGP routes to something less than 110. > ______________________________ > Saxon Jones > > Email: [email protected] > > > 2010/1/13 null zeroroute <[email protected]> > >> I'm having a problem trying to figure out a way to get eBGP learned >> routes >> (from a layer-3 VPN MPLS WAN provider) into our internal OSPF, so that the >> routes learned via the provider are preffered over the internally learned >> OSPF routes. >> >> No matter where the BGP-->OSPF redistribution point is, if it's the PE or >> CE, the routes will still show up (by default) as OSPF external, and will >> never be prefferred. >> >> The provider who's path we prefer will only run BGP. We would like to use >> OSPF everywhere if possible, for several reasons. >> >> WAN provider A is a layer-3 VPN MPLS network, and is the prefferred path. >> WAN provider B is a layer-2 VPN MPLS network over which we run OSPF. >> Provider B's network is inferior at times and we use it as a backup. >> >> The equipment where the eBGP peering relationsips exist is a mix of 7600, >> 3800, 2800, 1800, 6500, 3750, 3550. >> >> We considered GRE over the providers network however we then wind up with >> 25+ tunnels at each location, and that just grows as each new site is >> added, >> not to mention some potential issues regarding throughput with a GRE >> tunnel >> in the path. >> >> Is there a way to redistribute BGP into OSPF so that the routes can be >> anything but OSPF external? >> >> I have not found a way to do this yet, and was wondering if it's even >> possible, or if I'm missing something obvious. Any suggestions >> appreciated. >> _______________________________________________ >> cisco-nsp mailing list [email protected] >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> > > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
