[j-nsp] discard route resolveability in BGP path selection?

Pekka Savola pekkas at netcore.fi
Thu Feb 26 12:30:14 EST 2004


On 26 Feb 2004, Pedro Roque Marques wrote:
> pekkas at 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



More information about the juniper-nsp mailing list