[j-nsp] discard route resolveability in BGP path selection?
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 18.104.22.168 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?
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-
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
> 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