[c-nsp] bgp/ospf default route interaction

[Michael Ulitskiy]

Randy,
Thanks for the explanation.
I do understand the first part (without "always")
I guess what confused me is that I didn't expect a router would always prefer a locally injected
ospf default over the learned one. Since both LSAs are in the database (just checked it) I expected
it to go ahead and compare the metrics. In my example I specifically lowered the metric of default
advertised by CORE1 and it didn't make any difference. CORE2 still ignored it.
Anyway, it's much clearer now.
Thanks Randy and Christian,

Michael


On Monday 27 August 2012 17:32:04 Randy wrote:
> Hi,
> ..actually not quite!
> 
> case1: default-information-originate (core1 and core2)
> 
> core2 learns 3 defaults:
> via iBGP from core1 AD 200 but loc pref 150
> via eBGP from ISP2 AD 20 loc pref less than iBGP learned default
> via OSPF ad 110.
> 
> so on the face of it, it installs OSPF learned default in rib....what has happended in the process is that "default-information-originate" on Core2 *is NOT actually working*!
> 
> "default-information-originate" within OSPF *requires* that local router have a default-route known via any other igp/egp BUT NOT OSPF.
> 
> on to "default-information-originate *always*:
> 
> this causes localy router to inject a default into OSPF domain regardless of whether it has a default OR not.(remember it's default can never be via OSPF)
> 
> so what happens in the process is core2 suppresses OSPF learned default via core1 and now has iBGP default or eBGP default to choose from. It as a result chooses iBGP learned default in its rib.
> 
> (hint: in your original output, you will notice both eBGP and iBGP routes suffered from rib-failure...)
> 
> HTH wrt what is happening behind the scene.
> ./Randy
> 
> --- On Mon, 8/27/12, Michael Ulitskiy <mulitskiy at acedsl.com> wrote:
> 
> > From: Michael Ulitskiy <mulitskiy at acedsl.com>
> > Subject: Re: [c-nsp] bgp/ospf default route interaction
> > To: "Christian Meutes" <christian at errxtx.net>
> > Cc: "cisco-nsp" <cisco-nsp at puck.nether.net>
> > Date: Monday, August 27, 2012, 1:57 PM
> > Thanks for the reply.
> > So what you're saying is that if ospf router itself injects
> > ospf default in its ospf database then
> > it would ignore any other ospf defaults it might receive
> > (regardless of metric) and also it wouldn't 
> > install this default in the RIB. 
> > Did I get it right? 
> > I didn't know this rule and I'm a little surprised, but I
> > ran a few experiments and they seem to confirm it. 
> > Thanks,
> > 
> > Michael
> > 
> > On Monday 27 August 2012 16:06:14 Christian Meutes wrote:
> > > Hiho,
> > > 
> > > On Aug 27, 2012, at 7:52 PM, Michael Ulitskiy <mulitskiy at acedsl.com>
> > wrote:
> > > 
> > > > Now on CORE2 I add 'always' keyword to OSPF
> > 'default-originate' command,
> > > > making it:
> > > > 
> > > > CORE2: router ospf 100 default-information
> > originate always
> > > > 
> > > > For some reason I don't understand it changes the
> > game completely.  Now
> > > > IBGP route is preferred over OSPF
> > > 
> > > it's because you inject the 0/0 into OSPF on CORE2
> > *always*, effectively
> > > annihilating the other 0/0 advertised by CORE1s OSPF on
> > CORE2.
> > > 
> > > Thus, the only remaining defaults are the ones learned
> > via BGP.
> > > 
> > > Without the always-keyword it seems that the OSPF route
> > is learned fast
> > > enough to prevent the BGP one to be installed in.
> > > 
> > > 
> > _______________________________________________
> > 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/
> > 
>