Mailing List Archive

Tuesday, December 23, 2003, 1:52:25 PM, you wrote:
> No response on idr IETF list, so..

> I think Juniper's implementation/interpretation of accepted/rejected
> prefixes in the brand new BGP MIB is a bit funky, and loses some
> important information (this was tested on 6.1R1).

> Is it just me or should PrefixesAccepted include also those prefixes
> which passed through the BGP filters, but are currently inactive due
> to the existence of a route of better preference?


I think you need to see this from the RIB table perspective and
a route in hidden status ( which is vendor specific ) is from
the Loc-RIB point of view the same as inactive due to better
route preference. So when I look at the definition

jnxBgpM2PrefixInPrefixesAccepted

The number of prefixes for a peer that are installed
in the Adj-Ribs-In and are eligible to become active
in the Loc-Rib.


then I can only count the active routes. This is how it is done
since day one. So the MIB does only present what the CLI has
done since the very begin.


jnxBgpM2PrefixInPrefixesRejected
The number of prefixes for a peer that are installed
in the Adj-Ribs-In and are NOT eligible to become active
in the Loc-Rib.


So from here the routes which are not active due to attribute
tiebreakers or due to policies ( hidden ) or due to unresolved
next-hop ( hidden ) needs to be counted here.


What you are looking for is a private MIB which does
differentiate hidden routes versus inactive routes. aka
jnxBgpM2PrefixInPrefixesHidden or hidden routes due to local
policies.



<-- example on active routes and received routes for two peers

josefb@lab# run show bgp summary
Groups: 2 Peers: 4 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0 35250 30250 0 0 0 0
inet.2 0 0 0 0 0 0
bgp.l3vpn.0 0 0 0 0 0 0
bgp.l3vpn.2 0 0 0 0 0 0
inet6.0 0 0 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Damped...
192.1.1.2 64513 108 814 0 6 50:15 Establ
inet.0: 5100/5100/0
12.1.1.1 21 2148 6564 0 1 1:41:44 Establ
inet.0: 25150/30150/0
inet.2: 0/0/0
bgp.l3vpn.0: 0/0/0
bgp.l3vpn.2: 0/0/0




3.2 Routing Information Base

The Routing Information Base (RIB) within a BGP speaker consists of
three distinct parts:

a) Adj-RIBs-In: The Adj-RIBs-In store routing information that has
been learned from inbound UPDATE messages received from other BGP
speakers. Their contents represent routes that are available as an
input to the Decision Process.

b) Loc-RIB: The Loc-RIB contains the local routing information
that the BGP speaker has selected by applying its local policies
to the routing information contained in its Adj-RIBs-In. These are
the routes that will be used by the local BGP speaker. The next
hop for each of these routes MUST be resolvable via the local BGP
speaker's Routing Table.

c) Adj-RIBs-Out: The Adj-RIBs-Out store the information that the
local BGP speaker has selected for advertisement to its peers. The
routing information stored in the Adj-RIBs-Out will be carried in
the local BGP speaker's UPDATE messages and advertised to its
peers.








> ---------- Forwarded message ----------
> Date: Thu, 18 Dec 2003 15:02:03 +0200 (EET)
> From: Pekka Savola <pekkas@netcore.fi>
> To: idr@ietf.org
> Subject: BGP4 MIBv2 question on bgpM2PrefixInPrefixesAccepted

> Hi,

> (I'm not subscribed so please Cc:)

> I've a question on BGP MIBv2 bgpM2PrefixInPrefixesAccepted.

> What does "and are eligible to become active in the Loc-Rib"
> (intend to) mean? (see below for a snippet.)

> My interpretation is, "the prefix was accepted by possible inbound
> filters, but it may or may not be the active route in Loc-RIB".

> This obviously needs clarification as at least one implementation does
> not list prefixes which are accepted by BGP prefix/AS-path/etc.
> filters as Accepted if it doesn't win the best path decision process
> (e.g., if there is a route with better local-pref in your system).

> Obviously, this is very bad because the MIB does not offer any means
> to get the count of the "hidden" prefixes, which are accepted by the
> filters but not the best paths, if the above vendor's interpretation
> was true.

> (The point of this particular exercise is to get the SNMP access to
> information how well the prefix/AS-path/etc. filters are working
> towards a peer.)

> **** cut ******

> bgpM2PrefixInPrefixesAccepted OBJECT-TYPE
> SYNTAX Gauge32
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "The number of prefixes for a peer that are installed
> in the Adj-Ribs-In and are eligible to become active
> in the Loc-Rib."
> ::= { bgpM2PrefixCountersEntry 8 }


> bgpM2PrefixInPrefixesRejected OBJECT-TYPE
> SYNTAX Gauge32
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "The number of prefixes for a peer that are installed
> in the Adj-Ribs-In and are NOT eligible to become active
> in the Loc-Rib."
> ::= { bgpM2PrefixCountersEntry 9 }

Hi,

(Sorry for delay in responding..)

On Wed, 24 Dec 2003, Josef Buchsteiner wrote:
> Tuesday, December 23, 2003, 1:52:25 PM, you wrote:
> > No response on idr IETF list, so..
>
> > I think Juniper's implementation/interpretation of accepted/rejected
> > prefixes in the brand new BGP MIB is a bit funky, and loses some
> > important information (this was tested on 6.1R1).
>
> > Is it just me or should PrefixesAccepted include also those prefixes
> > which passed through the BGP filters, but are currently inactive due
> > to the existence of a route of better preference?
>
>
> I think you need to see this from the RIB table perspective and
> a route in hidden status ( which is vendor specific ) is from
> the Loc-RIB point of view the same as inactive due to better
> route preference. So when I look at the definition
>
> jnxBgpM2PrefixInPrefixesAccepted
>
> The number of prefixes for a peer that are installed
> in the Adj-Ribs-In and are eligible to become active
> in the Loc-Rib.
>
>
> then I can only count the active routes. This is how it is done
> since day one. So the MIB does only present what the CLI has
> done since the very begin.

No, I completely disagree about "can only count the active routes".
Look closer to the definitions:

The number of prefixes for a peer that are installed
in the Adj-Ribs-In and are ****eligible to become*** active
in the Loc-Rib.

Note that it does not say active, but "eligible to become active".
That reads IMHO very clearly that this is supposed to be a superset of
active routes (e.g., also including those routes which could become
active due to a route advertisement change).

Note that this definition does not even require that the prefixes to
be counted are in fact in Loc-RIB. If a route is eligible to become
active in the Loc-Rib, but exists only in an Adj-Rib-In (or something
similar, after applying policies etc.), that should be counted as
well. This seems to leave a door open to two implementation
techniques: multiple routes can exist in Loc-RIB (ie., anything
passing the first phase of route selection), or only one.

> jnxBgpM2PrefixInPrefixesRejected
> The number of prefixes for a peer that are installed
> in the Adj-Ribs-In and are NOT eligible to become active
> in the Loc-Rib.
>
>
> So from here the routes which are not active due to attribute
> tiebreakers or due to policies ( hidden ) or due to unresolved
> next-hop ( hidden ) needs to be counted here.

I think the Rejected counter should include the routes which are
hidden due to policies, or hidden due to unresolved next-hop.

(In the terms of draft-ietf-idr-bgp4-23.txt, anything that's rejected
before Phase 2 of Route selection, section 9.1.2.2.)

> What you are looking for is a private MIB which does
> differentiate hidden routes versus inactive routes. aka
> jnxBgpM2PrefixInPrefixesHidden or hidden routes due to local
> policies.

That would be an acceptable solution to the problem. As a matter of
fact, I'm going to push something like that to be included in BGP-V2
MIB when the IDR WG at IETF continues working on it.

> b) Loc-RIB: The Loc-RIB contains the local routing information
> that the BGP speaker has selected by applying its local policies
> to the routing information contained in its Adj-RIBs-In. These are
> the routes that will be used by the local BGP speaker. The next
> hop for each of these routes MUST be resolvable via the local BGP
> speaker's Routing Table.

Note that this, again, does not preclude having multiple routes to the
same destination in Loc-RIB.

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

Wednesday, December 31, 2003, 1:46:35 PM, you wrote:
> Hi,

> (Sorry for delay in responding..)

> On Wed, 24 Dec 2003, Josef Buchsteiner wrote:
>> Tuesday, December 23, 2003, 1:52:25 PM, you wrote:
>> > No response on idr IETF list, so..
>>
>> > I think Juniper's implementation/interpretation of accepted/rejected
>> > prefixes in the brand new BGP MIB is a bit funky, and loses some
>> > important information (this was tested on 6.1R1).
>>
>> > Is it just me or should PrefixesAccepted include also those prefixes
>> > which passed through the BGP filters, but are currently inactive due
>> > to the existence of a route of better preference?
>>
>>
>> I think you need to see this from the RIB table perspective and
>> a route in hidden status ( which is vendor specific ) is from
>> the Loc-RIB point of view the same as inactive due to better
>> route preference. So when I look at the definition
>>
>> jnxBgpM2PrefixInPrefixesAccepted
>>
>> The number of prefixes for a peer that are installed
>> in the Adj-Ribs-In and are eligible to become active
>> in the Loc-Rib.
>>
>>
>> then I can only count the active routes. This is how it is done
>> since day one. So the MIB does only present what the CLI has
>> done since the very begin.

> No, I completely disagree about "can only count the active routes".
> Look closer to the definitions:

> The number of prefixes for a peer that are installed
> in the Adj-Ribs-In and are ****eligible to become*** active
> in the Loc-Rib.

> Note that it does not say active, but "eligible to become active".
> That reads IMHO very clearly that this is supposed to be a superset of
> active routes (e.g., also including those routes which could become
> active due to a route advertisement change).

> Note that this definition does not even require that the prefixes to
> be counted are in fact in Loc-RIB. If a route is eligible to become
> active in the Loc-Rib, but exists only in an Adj-Rib-In (or something
> similar, after applying policies etc.), that should be counted as
> well. This seems to leave a door open to two implementation
> techniques: multiple routes can exist in Loc-RIB (ie., anything
> passing the first phase of route selection), or only one.

this means you prefer non-visibility of true active routes per
peer ?


Josef