[c-nsp] OSPF and BGP relationship

Mon Mar 2 21:53:23 EST 2015

Not to beat a dead horse, but if you were able to get rid of OSPF between
MAN links associated with A, B, C, and D and only use it for IGP at that
specific local site you could use BGP per neighbor policies to affect
outbound traffic flow with both of your internet edge routers just using
BGP originated default from the ISP edge routers and OSPF
default-information originate at the local sites towards your LAN. It
wouldn't give you outbound granularity on a per-prefix basis, but it would
at least allow you to have say Router C prefer router A as egress and
Router D to prefer router B as egress. This would be as simple as attaching
a route-map to that neigbor on C and D so their incoming weight of the 0/0
route was preferred over the other routers copy of the 0/0 route.

Of course this would require you to make sure your LAN networks at the
sites are being advertised into iBGP so no reachability issues would be
experienced. Full mesh or route-reflectors, etc. BGP is infinitely more
flexible for traffic engineering than OSPF is, which is why I'm suggesting
this option in the event you aren't able to receive full routes and you're
OK with basic outbound 'load sharing'.

On Mon, Mar 2, 2015 at 8:07 PM, Network <network at cwo.com> wrote:

> I should have mentioned that I'm only getting a default route from my
> upstream providers. I guess I could request a full table, as we have enough
> resources to handle it on the edge routers. In the past there has not been
> a convincing reason to receive a full bgp route table.
>
> Just curious, how large,in megabytes, is the current bgp table?
>
> JB
>
>
> On Mar 2, 2015, at 5:11 PM, Clint Wade <jarod.wade at gmail.com> wrote:
>
> 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 <aaron1 at gvtc.com> 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:cisco-nsp-bounces at puck.nether.net] On Behalf Of
>> CWO Network Operations
>> Sent: Monday, March 02, 2015 3:40 PM
>> To: cisco-nsp at puck.nether.net
>> 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  cisco-nsp at 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 at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>
>