Everything I'm stating below here is under the assumption you're receiving a full route table from the ISP's and not just a default route. If all you're getting is a default, you're looking at something like policy based routing or possibly PFR to fix this as far as I know.
Weight and Local Pref to affect outbound --> You'll want it higher on the one you want to be the exit point and as long as you have an iBGP connection between your two BGP edge routers you'll be ok. If no iBGP link between your two edge routers exists then affecting outbound is impossible as you're limited by OSPF and the best you can do is force one to be the outbound for all prefixes. Another way I've seen done what you're doing is to originate 1 default in OSPF as Type 1 and the other as Type 2, obviously the exit path to the Type 1 route is preferred, but once it makes it to that edge router you'll have to rely on BGP path selection to affect which edge router to egress for specific prefixes, which is why the iBGP link is required. AS Path and MED to affect inbound --> Usually done by sending communities to your providers to affect their routes; Each provider has a list of communities they accept to perform functions such as 'Add 4x AS# to existing AS_Path' or 'Set local pref' on the provider side. You'll need to use a looking glass server to verify these changes, and you'll want to check them from a couple different providers looking glass to see what effects it has on routing outside of the provider you're trying to traffic engineer. Keep in mind you have to be careful as some providers transit to other provider connections can get saturated which can lead to some unexpected side affects, so you'll have to keep a close eye on performance (latency, etc.) On Mon, Mar 2, 2015 at 4:12 PM, Aaron <[email protected]> wrote: > I also have 2 (working on 3) Internet connections and only learn default > route from upstream provider.... > > I don’t know if this is best/common practice but if I ever prefer a /32 to > exit out one of my particular internet connections, I'll point a static /32 > out that internet connection and redistribute it into my igp....my igp > happens to be mb-ibgp for my l3vpn's to rcv it across my mpls network. > > Aaron > > -----Original Message----- > From: cisco-nsp [mailto:[email protected]] On Behalf Of > CWO Network Operations > Sent: Monday, March 02, 2015 3:40 PM > To: [email protected] > Subject: [c-nsp] OSPF and BGP relationship > > I have a question about the common practice of using OSPF and (i)bgp. > > Here is my setup: > > > I have 4 Cisco routers (A, B, C & D). All routers are connected to each > other through metro ethernet connections. The 4 routers have other “stuff” > behind them speaking only OSPF and require a injected default route. > Router A and B are connected to different internet backbone providers > using BGP. > Internally I use iBGP and OSPF. I do not redistribute OSPF routes into > BGP, nor do I do the opposite. > Router A injects a default route into the network using OSPF’s > default-information originate metric 100. > Router B also injects a default route into the network using OSPF’s > default-information originate metric 110. > > So, right now all my outbound traffic goes out through router A (because > of the metric 100). Inbound traffic comes through both internet > connections, based on the preferred BGP route. > Since the IGP (ospf) has the lower IGP metric (in comparison to ibgp) the > ospf default routes (0.0.0.0/0) routes determine the flow of outbound > traffic. Because of that, I can’t seem to “direct” outbound traffic using a > local route map (local-preference). Ideally I would like to be able to > direct outbound traffic as specific as I like. > > What is the common setup, in terms of BGP and OSPF, on networks that > resemble ours? > > Thanks > JB > > > > > _______________________________________________ > 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/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
