[j-nsp] BGP4 MIBv2 question on bgpM2PrefixInPrefixesAccepted (fwd)

[Josef Buchsteiner]

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 at 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 at netcore.fi>
> To: idr at 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 }