Mailing List Archive

pekkas@netcore.fi (Pekka Savola) writes:

> In particular, when there exists a (default) discard route which
> always matches the nexthop even if the OSPF route is removed, are the
> BGP routes still considered resolveable

Yes. Althought there is some magic to mark it has the lowest metric of
all.

>, or are they removed from
> consideration? (draft-ietf-idr-bgp4-23.txt sect 9.1.2.1 is a bit
> ambiguous on that that but I assume they should be removed, but I
> think they weren't.)
>

I don't think there is any ambiguity... any route should be usable for
resolution purposes, by default.

What is the point of having a default discard route ? Why don't you
just remove it.

Pedro.

On 26 Feb 2004, Pedro Roque Marques wrote:
> pekkas@netcore.fi (Pekka Savola) writes:
> >, or are they removed from
> > consideration? (draft-ietf-idr-bgp4-23.txt sect 9.1.2.1 is a bit
> > ambiguous on that that but I assume they should be removed, but I
> > think they weren't.)
> >
>
> I don't think there is any ambiguity... any route should be usable for
> resolution purposes, by default.

Is there a way to change that behaviour?

from 9.1.2.1:

2. Routes referencing interfaces (with or without intermediate
addresses) are considered resolvable if the state of the refer-
enced interface is up and IP processing is enabled on this inter-
face.

I would consider "discard" as a "null" interface. Whether such an
interface should be "up" or not might be up for debate. Certainly, it
would make a lot of sense to explicitly exclude any discard routes as
unresolveable!

> What is the point of having a default discard route ? Why don't you
> just remove it.

We want to to send only default BGP route to some peers, and we
generate that from the discard route. Any other way to achieve that?
(Futzing around in documentation indicates that setting these routes,
additionally, as 'no-install' might get the behaviour we want. Is
this true? Any other options?)

By the way, is it possible to specify that the routes used for BGP
resolveability checks must have lower preference than FOO. That is,
keeping all the p-t-p and OSPF addresses in OSPF, I'd like to avoid
the BGP resolvability process considering BGP routes?

This is pretty important, as if I understand you correctly, to make
the resolvability fail as it should, there must not be any less
specific route to the loopback/p-t-p addresses, and we have plenty for
aggregation etc. purposes.

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

On Thu, Feb 26, 2004 at 09:05:41AM -0800, Pedro Roque Marques wrote:
> What is the point of having a default discard route ? Why don't you
> just remove it.

Because

- he doesn't want to reply ICMP Unreachables?

- he needs the default route because JunOS doesn't have
"default-originate" for IGP/BGP as Cisco has?



Regards,
Daniel

On Thu, Feb 26, 2004 at 07:30:14PM +0200, Pekka Savola wrote:
> > I don't think there is any ambiguity... any route should be usable for
> > resolution purposes, by default.
>
> Is there a way to change that behaviour?
>
> from 9.1.2.1:
>
> 2. Routes referencing interfaces (with or without intermediate
> addresses) are considered resolvable if the state of the refer-
> enced interface is up and IP processing is enabled on this inter-
> face.
>
> I would consider "discard" as a "null" interface. Whether such an
> interface should be "up" or not might be up for debate. Certainly, it
> would make a lot of sense to explicitly exclude any discard routes as
> unresolveable!

I concur. Would be nice and make a whole lot of sense.

> We want to to send only default BGP route to some peers, and we
> generate that from the discard route. Any other way to achieve that?
> (Futzing around in documentation indicates that setting these routes,
> additionally, as 'no-install' might get the behaviour we want. Is
> this true?

no-install means that it doesn't get installed in the FIB, but it's
still present in the RIB. As BGP uses RIB for next-hop resolution,
I somewhat doubt that no-install changes anything.

> Any other options?)

AFAIK no. Juniper said that they didn't want to implement special
knobs like default-originate if this can be done by using static
routes and standard policy filtering.

> By the way, is it possible to specify that the routes used for BGP
> resolveability checks must have lower preference than FOO. That is,
> keeping all the p-t-p and OSPF addresses in OSPF, I'd like to avoid
> the BGP resolvability process considering BGP routes?

set protocols bgp group foo protocol ospf

This makes next-hop resolution consider only OSPF-learned routes.


Best regards,
Daniel

On Thu, 26 Feb 2004, Daniel Roesen wrote:
> set protocols bgp group foo protocol ospf
>
> This makes next-hop resolution consider only OSPF-learned routes.

Hmm. it seems only 'ospf' or 'isis' are supported. How does this
treat 'direct', 'local', etc. routes then? They are preferable to
OSPF/IS-IS routes :).

I guess the implementation allows those implicitly?

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

dr@cluenet.de (Daniel Roesen) writes:

>
> set protocols bgp group foo protocol ospf
>
> This makes next-hop resolution consider only OSPF-learned routes.
>
>
That option doesn't do anything in releases > 5.0. It has been removed
(hidden) in latest releases.

Pedro.

On Thu, Feb 26, 2004 at 05:27:18PM -0800, Pedro Roque Marques wrote:
> dr@cluenet.de (Daniel Roesen) writes:
> > set protocols bgp group foo protocol ospf
> >
> > This makes next-hop resolution consider only OSPF-learned routes.
> >
> That option doesn't do anything in releases > 5.0. It has been removed
> (hidden) in latest releases.

Uhm, not really:

# set protocols bgp group foo ?
Possible completions:
[...]
protocol IGP to use to resolve the next hop
[...]

This is 6.2R1.5

And the 6.2 docs still contain it too:
http://www.juniper.net/techpubs/software/junos/junos62/swconfig62-routing/html/bgp-summary38.html#1015141

With no mentioning that it's without effect.


Regards,
Daniel

So, for clarity, the default is that all routes are considered viable for
next-hop-availability, including another bgp route, or is bgp excluded?

In either event, since most of us carry the aggregates and some a default,
what is the default scan-time and can I change it? I know I can change the
BGP timers but its naturally a much better solution to have a low scan
interval for next-hop validation check...

damon.

> -----Original Message-----
> From: Daniel Roesen [mailto:dr@cluenet.de]
> Sent: 27 February 2004 02:07
> To: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] discard route resolveability in BGP path
> selection?
>
>
> On Thu, Feb 26, 2004 at 05:27:18PM -0800, Pedro Roque Marques wrote:
> > dr@cluenet.de (Daniel Roesen) writes:
> > > set protocols bgp group foo protocol ospf
> > >
> > > This makes next-hop resolution consider only OSPF-learned routes.
> > >
> > That option doesn't do anything in releases > 5.0. It has
> been removed
> > (hidden) in latest releases.
>
> Uhm, not really:
>
> # set protocols bgp group foo ?
> Possible completions:
> [...]
> protocol IGP to use to resolve the next hop
> [...]
>
> This is 6.2R1.5
>
> And the 6.2 docs still contain it too:
> http://www.juniper.net/techpubs/software/junos/junos62/swconfi
g62-routing/html/bgp-summary38.html#1015141

With no mentioning that it's without effect.


Regards,
Daniel
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp

We do not have time driven resolution of bgp nh, so there is no scan
timer to change. Unlike Cisco we have an event driven resolver i.e.
when next hops change then the resolver runs and updates bgp nh as
necessary at that instant.

Gary

On Mar 2, 2004, at 6:43 AM, Damon Pegg wrote:

> So, for clarity, the default is that all routes are considered viable
> for
> next-hop-availability, including another bgp route, or is bgp excluded?
>
> In either event, since most of us carry the aggregates and some a
> default,
> what is the default scan-time and can I change it? I know I can
> change the
> BGP timers but its naturally a much better solution to have a low scan
> interval for next-hop validation check...
>
> damon.
>
>> -----Original Message-----
>> From: Daniel Roesen [mailto:dr@cluenet.de]
>> Sent: 27 February 2004 02:07
>> To: juniper-nsp@puck.nether.net
>> Subject: Re: [j-nsp] discard route resolveability in BGP path
>> selection?
>>
>>
>> On Thu, Feb 26, 2004 at 05:27:18PM -0800, Pedro Roque Marques wrote:
>>> dr@cluenet.de (Daniel Roesen) writes:
>>>> set protocols bgp group foo protocol ospf
>>>>
>>>> This makes next-hop resolution consider only OSPF-learned routes.
>>>>
>>> That option doesn't do anything in releases > 5.0. It has
>> been removed
>>> (hidden) in latest releases.
>>
>> Uhm, not really:
>>
>> # set protocols bgp group foo ?
>> Possible completions:
>> [...]
>> protocol IGP to use to resolve the next hop
>> [...]
>>
>> This is 6.2R1.5
>>
>> And the 6.2 docs still contain it too:
>> http://www.juniper.net/techpubs/software/junos/junos62/swconfi
> g62-routing/html/bgp-summary38.html#1015141
>
> With no mentioning that it's without effect.
>
>
> Regards,
> Daniel
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
>

damon.pegg@uk.easynet.net (Damon Pegg) writes:

> So, for clarity, the default is that all routes are considered viable for
> next-hop-availability, including another bgp route

Yes.

>, or is bgp excluded?

No, it is not. It is perfectly valid (and used by quite a few
networks) to have several levels of recursion.. i.e. a BGP route that
resolves over a BGP route that resolves over an IGP route.

Pedro.