Subject: [Idr] BGP MIB v2 input

From: "Susan Hares" <[email-masked]>
Date: Wed, 21 Mar 2007 04:22:22 -0600

Working group:

Simon Leinen and Pekka Savola indicated the current MIB is not
sufficient,

And that portions of BGP MIBv2 that allow operators to see the:

-       amount of prefixes received, and

-       amount of prefixes filtered.

Please send what in BGP MIB v2 is useful to you.

The BGP MIB v2 has been in limbo for 5 years due to lack of feedback. 

We would like to encourage feedback from operators who actually use
these variables. 

Please send what variables you use to the list.

Sue Hares

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Simon Leinen <[email-masked]>
Date: Wed, 21 Mar 2007 16:05:34 +0100

> Simon Leinen and Pekka Savola indicated the current MIB is not

For reference, the current MIB is now RFC 4273, which is almost
identical to the venerable RFC 1657.  The "MIBv2" I-D has expired (not
for the first time), but can be retrieved from:
    http://tools.ietf.org/wg/idr/draft-ietf-idr-bgp4-mibv2/

> -       amount of prefixes filtered.

Pekka raised these, and as an operator, I would also find them quite
useful for monitoring peerings' sanity (peer going berserk?) and
evolution (when it might be time for me to update filters,
max-prefixes, get rid of the peering because it has become
insignificant etc.)

They are available in MIBv2 as "bgpM2PrefixInPrefixes" (number of
prefixes currently received from a peer for an address family), and
"bgpM2PrefixInPrefixesAccepted/bgpM2PrefixInPrefixesRejected",
respectively.  It seems to me that these three variables are slightly
redundant (although as an operator, I should probably like redundancy
:-), as ...InPrefixes = ...InPrefixesAccepted + ...InPrefixesRejected.

(I asked a MIB doctor who happened to be sitting next to me, and he
said it would be better to avoid this kind of redundancy in a MIB.)

> Please send what in BGP MIB v2 is useful to you.

Definitely useful:

Everything that's under bgpM2PrefixCountersTable (except one of the
three objects mentioned above, to remove the redundancy).

I especially like the fact that this table (and all others) allow
peerings over IPv6 to be monitoring.  We cannot currently do this in
our network, and that is a pain.

> We would like to encourage feedback from operators who actually use

We cannot use them since they don't exist, but we would use them
almost instantly if we had software that supported them, even in
vendor-specific variants.

-- 
Simon.

---

From: Henk Uijterwaal <[email-masked]>
Date: Thu, 22 Mar 2007 09:22:45 +0100

Simon and others:

>> Please send what in BGP MIB v2 is useful to you.

It supports 32 bit AS Numbers, the current MIB doesn't as it says:

  bgpPathAttrASPAth OBJECT-TYPE
    SYNTAX OCTET STRING (SIZE (2..255))
    [...]
    EAch AS is represented as a pair of octets according to the following
    algorithm:
      first-byte-of-pair = ASNumber / 256
      second-byte-of-pair = ASNumber & 255;

  [...]

   bgpPeerRemoteAs OBJECT-TYPE
     SYNTAX  Integer32 (0...65535)

Either one will fail for AS1.0 and everything beyond that.  The new draft has
an AS type that fixes this.

Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

# Lawyer: "Now sir, I'm sure you are an intelligent and honest man--"
# Witness: "Thank you. If I weren't under oath, I'd return the compliment."

---

From: Bill Fenner <[email-masked]>
Date: Mon, 26 Mar 2007 06:50:37 +0100

It may be worth breaking this down into areas of limitation of the
current MIB:

1. v6 peer support
2. v6 and other NLRI support
3. 4-byte AS support
4. extra counters desired
(Others?)

#1 can be taken care of with a rev of the peer table using
the InetAddressType/InetAddress TCs.

For #2, I have a somewhat radical proposal, which is to eliminate
the reporting of the BGP table contents via SNMP.  The radical
replacement would be a "lookup request" which you do by writing
an AFI, SAFI, NLRI to a lookup table, specifying whether you want
longest match or all matches, and you read the results from a
lookup results table.

(a few reasons for this change:
a) It's not very efficient to have an SNMP table with 200k+ rows;
b) It's hard to represent, e.g., VPN routes; and
c) You probably want to know "what routes do you know for
this destination", which is not easy to answer even with the
existing indexing, since "destination" is probably a /32 and
the prefix in the table is probably not)

#3 is straightforward, especially since between #1 and #2
we're probably changing most of the places you see an
AS number anyway.

#4 is straightforward too if we know exactly which counters are
useful.

Although there are problems that the original BGP MIBv2 effort
tried to solve that aren't on my list, I'd propose ignoring them
for now in order to make *some* progress.

  Bill

---

From: Pekka Savola <[email-masked]>
Date: Mon, 26 Mar 2007 08:40:40 +0300 (EEST)

> 4. extra counters desired
..

As I mentioned at the mike, I believe the counters for prefixes 
rejected by policy (whether this also includes AS-path loops, invalid 
next-hops etc. doesn't matter to me) apart from those that are 
accepted by policy but not necessarily the preferred ones right now.

This can be used for monitoring how well BGP prefix filters etc. are 
functioning.  As a bonus, it'd be nice to be able to see which 
prefixes are stuck in the inbound policy filter, but that's not 
mandatory.

Support for reporting information on IPv6 peers and non-IPv4 NLRIs 
would also be very welcome.

...

Below is some information about what some implementations do:

Juniper reports the following support on their web page (which we are 
already using) for JunOS:

==8<==
Internet draft draft-ietf-idr-bgp4-mibv2-04.txt, Definitions of 
Managed Objects for the Fourth Version of Border Gateway Protocol 
(BGP-4), Second Version (only the objects jnxBgpM2PrefixInPrefixes, 
jnxBgpM2PrefixInPrefixesAccepted, and 
jnxBgpM2PrefixInPrefixesRejected)
==8<==

[Note: they actually support slightly more than that, e.g., most 
or all of peer-status objects, but for example not dumping all the 
BGP routes using SNMP.]

With the MIB at:

http://www.juniper.net/techpubs/software/junos/junos82/swconfig82-net-mgmt/html/mib-jnx-bgpmib2.txt

Note: Juniper's current implementation of 
BgpM2PrefixInPrefixesRejected is broken as it counts all non-active 
routes instead of those rejected by policy.

Surfing around a bit, Cisco IOS XR 3.4 at least claims to support 
draft-ietf-idr-bgp4-mibv2-05.txt (though under 'BGP Next Hop Tracking 
enhancements' so I suspect they don't implement the full MIB either).

In some other software trains, Cisco also seems to support some of the 
features of the new BGP mib, such as the number of 'received routes' 
but not the whole MIB as such:

http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a00802259e0.html#wp1059248

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

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 26 Mar 2007 09:32:50 -0400

> the prefix in the table is probably not)

#2 is an intriguing idea. Existing UI implementations already cover
having multiple "processes" access the routing table simultaneously.
However, I think this may have some interesting implementation
headaches.  Could you please comment on them?

- This would require set/write access to the MIB, correct?  If so,
  that's one of the things that people expressed serious reservations
  about for any purpose previously.  If not, are people on board with
  dynamic queries using get operations where getnext wouldn't work?
- The results would likely be some sort of dynamically created OID tree
  for each query.  UIs such as a CLI tend to have reasonably well
  understood lifetimes for their route table walking routines, but MIBs
  have a much less well defined interface.  Additionally, if you're
  running the same query over and over, you may end up with multiple
  views instatiated which may have excessive overhead.  Further, you
  don't have any sort of static OID you can use to monitor the state of
  a particular route.
- The results of this query would seem to be the same MIB structure as
  one would have for the entire routing table.  MIB structure-wise, I
  don't think we save any complexity.

If these premises are true to one extent or another, that still leads to
an interesting possibility.  We could still have the necessary query
objects.  The result would then be a rowpointer to the root of the
existing routing table's subtree that matched the query.  There would be
no need to dynamically generate views of the routing table, however
there would need to be a little intelligence in the querying routine to
stop walking after you've hit a less specific route.

> we're probably changing most of the places you see an

The choice I made in the updates was to simply have the base routing
table be 4-byte aware.  The annoying case is a 2-byte to 4-byte
transition speaker where three versions of the objects may be present:
The active derived set, the received 2-byte path attributes and the
received 4-byte path attributes.  In the interest of simplicity in the
base MIB, I'm suggesting the additional transitional views be left to an
extention MIB.

-- Jeff

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 26 Mar 2007 12:18:13 -0400

> base MIB, I'm suggesting the additional transitional views be left to an

Jeff,

Regarding #2 above.

If we are going to play games that allow stateful SNMP access to solve
the routing table dump problem I suggest we create a MIB pseudo write
to take a snapshot of the routing table with a given identifier.  The
snapshot could then be transferred gradually but would 1) provide a
consistent view (atomic operation) of the routing table, 2) incur
little load on the router.  The snapshot would have limited lifetime
and could be refused if load was high (too many NMS stations asking
for snapshots, etc).

For routers that happen to have a fork operation with copy-on-write
semantics this would be a very minimal impact and be similar to the
"gated dump" of olden days.  The forked process would then answer MIB
queries.  Separate memory pages would exist only as a result of routes
that change during the lifetime of the snapshot.

Routers built on more primative OS could implement the snapshot in
some other way, but could incorporate a copy-on-write semantic within
the routing table itself (with some complexity in doing so but that's
their fault for not using a modern OS).

As is (current MIB) from a practical standpoint the BGP routing table
cannot be dumped via SNMP.  Either you have to try to be aggressive
and get it fast, or it changes while being dumped.  I'm not sure if
anyone has implemented a TCP GET-BULK on the entire routing table as a
fork with copy-on-write, but that would have the same effect.  The
process making the TCP transfer could be given a low priority making
the operation atomic yet low impact.  If that is an acceptable
alternative, then no change is needed.

I'm not sure if this addresses one implied requirement (or imagined on
my part?) of #2 above, which is to dump a specific prefix only.  I
thought that would already be possible with GET-NEXT and the existing
ordering used in the MIB.

Disclaimer - I'm far from an SNMP expert.

Curtis

ps - No I don't work for Juniper.  :-)

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 26 Mar 2007 13:17:46 -0400

Curtis,

On Mon, Mar 26, 2007 at 12:18:13PM -0400, Curtis Villamizar wrote:
> to take a snapshot of the routing table with a given identifier.

I may have mis-interpreted Bill, but I think he simply wanted a better
way to get at a specific set of routes rather than an atomic routing
table dump.  When I was pondering the "sub-view" problem, I had many of
the same thoughts you put in your reply.  My next thought was, 
"Ew, gross!"

I think the snapshot mechanism may be nice for some implementations, but
I'd hesitate to recommend it go into the IETF standard mib for BGP.

> cannot be dumped via SNMP.

[All very much IMO:]

I'd agree.  I also don't know if it's the right problem to be solved.
SNMP is very good at getting you to specific instances of some data.  It
is okay for getting you the "next" data instance, but its idea of "next"
is a bit weak for routing table dumps.  

As a data abstraction format, it has some ugly limits.  You're
recommended to not use OCTET STRINGs longer than 255 bytes, but BGP has
several object that in binary format would be longer than that.  This
has meant that canonicalizing objects such as AS_PATHs require a pointer
to another table which breaks out the elements into effectively an array
of an array.

As an abstract data transport, it's weak in that it wants a pull rather
than a push.  This means that you end up making several potentially
expensive API calls to your routing table to pull data with the
possibility of caches going stale due to the time involved.  This may be
less so with GETBULK, but that depends on the user.

> ordering used in the MIB.

Fetching a specific prefix is easy.  Bill's suggestion was "fetch the
most specific prefix" or "fetch more specific prefixes".  The current
RFC 4273 MIB would return data:

        bgp4PathAttrEntry OBJECT-TYPE
            SYNTAX     Bgp4PathAttrEntry
            MAX-ACCESS not-accessible
            STATUS     current
            DESCRIPTION
                    "Information about a path to a network."
            INDEX { bgp4PathAttrIpAddrPrefix,
                    bgp4PathAttrIpAddrPrefixLen,
                    bgp4PathAttrPeer            }
            ::= { bgp4PathAttrTable 1 }

Prefix (an ip addres), followed by the prefix length, followed by the
peers who have that prefix.  (The update actually has the indexes the
other way - all routes for a peer.  That's broken and I'll fix it.)

This means that 10.0.0.0/8 and more specific will give you something
like:
10.0.0.0/8
10.0.0.0/9
10.1.0.0/24

You and I would expect 10.1/24 to fall after 10/8 as a more specific,
but SNMP wouldn't.  This lexicographic threading of a radix trie already
gives developers heartburn and introduces all sorts of fun
inefficiencies.

Perhaps the better question to ask is, "Is having access to the routing
table via SNMP even worth it?"  After several years of thinking about
this (and a little bit of time before that as an operator), I think the
answer is "maybe", but certainly not for dumping.  I've provided a
representation that lets you do it.  I can't even argue it's the best
one, but I seemed to have played "stump the mib doctor" a few times over
the past few years. :-)

-- Jeff

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 26 Mar 2007 14:21:10 -0400

> This means that 10.0.0.0/8 and more specific will give you something

That's not terrible for the NMS.  GET-NEXT on 9.255.255.255/32 and get
10/x or GET-NEXT on 10/7 and walk 10/8, 10/9, etc until you are out of
the 10/8 range (in a prefix/mask sense).

The ordering in effect requires two trees in the router, one for the
normal radix trie acxess and one for the MIB.  At least that is what
one implementation does.  Fixing the ordering would eliminate that.

> one, but I seemed to have played "stump the mib doctor" a few times over

IMO Its useful for enterprise but currently not practical for ISPs.
As a result ISPs don't dump the routing table or use SNMP to query the
routing table for debugging, but instead use other means.

If it could be made useful for ISPs it would make the job of writing
NOC software tools and ISP NMS tools all the easier.

The only use I found for periodically dumping the routing table was to
check for inconsistency across a network due to some vendors MED
handling and non-deterministic route install issues.  You could say
BGP was a bit more buggy then.  ISPs today might only find it
interesting to periodically see how non-deterministic routing choices
fall if they are doing traffic matrix estimation in a BGP/IGP only (no
MPLS TE) network which some (most?) do for planning purposes.

Curtis

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 26 Mar 2007 14:40:45 -0400

> the 10/8 range (in a prefix/mask sense).

Right, but that means the NMS isn't a very good tool to manage your
router when looking at routing tables.  People want prefix order, not
MIB order.

> one implementation does.  Fixing the ordering would eliminate that.

Every router that implements the MIB would have to do something like
this.  Sane ones (presumably IMO) all just keep the routes on two trees.
Less sane ones that are less sensitive to scaling may have copies of
routing information.

> NOC software tools and ISP NMS tools all the easier.

<zathras>This is wrong tool</zathras>

To re-ask the question - drop the routing database from the MIB?

-- Jeff

---

From: Pekka Savola <[email-masked]>
Date: Mon, 26 Mar 2007 22:50:18 +0300 (EEST)

> To re-ask the question - drop the routing database from the MIB?

Just wondering: the current BGP4 MIB already supports the routing 
databse (BGP4-MIB::bgp4PathAttrBest at least).  Are you proposing 
dropping the equivalent functionality from the new MIB or just some 
more exciting new variants?

Similar information for the whole FIB exists under IP-FORWARD-MIB.

Both are widely implemented AFAIK, which seems like a proof that an 
implementation is feasible.

FWIW, I agree that using SNMP to dump 200K+ prefixes from routing 
tables across all routers is likely not very useful in most cases, 
especially if you want to compare the tables, as the tables are going 
change over time. (Though in restricted contexts like without DFZ this 
may or may not be useful.)

An example: I currently use both IP-FORWARD-MIB and 
BGP4-MIB::bgp4PathAttrBest in SNMP scripts by parsing the config files 
(interface-related routing protocol config to be exact) and checking 
them against operational policy (e.g., certain kinds of interface 
addresses must be in OSPF; others must not be in OSPF; some others 
must be in BGP; static routes must be in BGP; etc.).

---

From: Bill Fenner <[email-masked]>
Date: Mon, 26 Mar 2007 22:16:13 +0100

>more exciting new variants?

That was my proposal, since getting a pathattr table that
nicely handles IP and non-IP NLRI is ... confusing.  It also
can result in less than ideal behavior when walking the whole
MIB on a device that has hundreds of thousands of prefixes.

>must be in BGP; static routes must be in BGP; etc.).

Interesting.  I was looking it from the point of view of not knowing
exactly what prefix you were looking for (e.g., "show ip bgp 12.106.35.1"
without knowing that it's in a /22).  The obvious thing to do is to grab
the whole table (probably inadvisable); there are more subtle ways but
none are very efficient.

  Bill

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 26 Mar 2007 16:32:42 -0400

> more exciting new variants?

A deficiency that I had originally been asked to address in the second
version of the MIB was access to structured data.  I'll give two
examples:

- The AS_PATH in the RFC 4273 MIB is contained in:

        bgp4PathAttrASPathSegment OBJECT-TYPE
            SYNTAX     OCTET STRING (SIZE (2..255))
            MAX-ACCESS read-only
            STATUS     current

Pretty much memcpy() the AS_PATH into the MIB and truncate.
This had two issues:
1) It's truncated in some circumstances
2) It required the management appliance to have a function that could
parse AS_PATHs (and potentially truncated ones at that).

That's not useful.  For the AS_PATH, we probably want two pieces of
data:
1) Something humanly readable
2) Something that's a canonicalized version of the data structure that
doesn't lose information.

These can be solved using roughly this structure:
NlriTable contains pathattrindex
PathAttrTable[pathattrindex] contains path attributes:
 - MED, etc.
 - Human readable AS_PATH
 - aspathindex

AsPathTable[aspathindex][subindex] is a table that canonicalizes the
entirety of the AS_PATH.

Problems with this representation:
- The human readable bit will likely be vendor specific.  That's okay as
  long as we have something canonical.  However, it's going to be
  limited to 255 characters courtesy of SnmpAdminString
- The AsPathTable is convoluted enough that you probably still don't
  want to look at it.It could be interpreted by a human without decoding
  TLVs in your head, but it's still not pretty.  *However*, it is
  cachacble.

The second example is communities.  It has all of the same problems.
Additionally, communities aren't required to be supported in order to do
BGP.  This means putting them in the base BGP mib is probably a bad
idea.  You still want the data, so you put them in an extensions mib.

Note: IDR feedback has had me try things both ways over the last several
years with regards to extentions/not extentions.

> Similar information for the whole FIB exists under IP-FORWARD-MIB.

With all respect to that MIB author: The data was easier to represent.

> must be in BGP; static routes must be in BGP; etc.).

I think this answers some of Curtis' questions. :-)

-- Jeff

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 26 Mar 2007 18:48:17 -0400

> router when looking at routing tables.  People want prefix order, not

A MIB dump is never a good tool.  A tool that uses the MIB could
reorder such a query.

I've already agreed with you that radix trie order would be better.

> Less sane ones that are less sensitive to scaling may have copies of

Extra copies?  Might be worth taking this off list.  Could have humor
value.

btw- Really bad first implementations might try to scan the routing
table for each GET or GET-NEXT.  There is existance proof of this.

> To re-ask the question - drop the routing database from the MIB?

All IMHO ...

If its useful for enterprise it shouldn't be dropped in the MIB just
because it is not useful for ISPs.

I think it can become ever so slightly more useful for ISPs if the
sorting order is changed.  It can also become less of a burden on
routers if the sorting order is changed.  Then any good reason to drop
it is eliminated.

At most a router can have a knob to disable it (and save the trouble
of creating the extra tree if using the old sorting order).

If some router running an OS with VM copy-on-write semantics
implements a TCP GET-BULK dump of full BGP routing table as a special
case using a fork to make the operation efficient, more power to
them.  Some ISPs might think thats great.  Others might not case as
long as it can't become a means of denial of service attack.

I think I've said enough so shutting up now.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 26 Mar 2007 19:00:43 -0400

> MIB on a device that has hundreds of thousands of prefixes.

I completely missed the non-IP issue here with the need for a MIB
entry and sorting order covering both IP and non-IP.

> the whole table (probably inadvisable); there are more subtle ways but

More likely do GET on a 12.106.35.1/32, and decrement prefix length to
/31, etc, until something comes up.  Not terribly efficient either.
The route covering this could be 0/0.

To handle IP and non-IP cleanly you almost need an object oriented MIB
entry, where one order is used for IP and other types can define other
orders.  No such thing in SNMP AFAIK.

Curtis

---

From: Pekka Savola <[email-masked]>
Date: Tue, 27 Mar 2007 08:52:02 +0300 (EEST)

off-list,

> MIB on a device that has hundreds of thousands of prefixes.

If non-IP NLRI's are considerably difficult, maybe those should not be 
presented in the MIB (at least in the basic version)?

> the whole table (probably inadvisable); there are more subtle ways but

I'm not sure how the SNMP agent implementation actually does it (i.e. 
whether it needs to do memory copy of the whole table), but this what 
I do is without a subnet mask (because I have been too lazy to convert 
it between different prefix length representations :-):

$ snmpwalk -v 2c -c $comm -m BGP4-MIB $rtr bgp4PathAttrBest.193.167.190.0

BGP4-MIB::bgp4PathAttrBest.193.167.190.0.25.172.31.5.199 = INTEGER: true(2)
BGP4-MIB::bgp4PathAttrBest.193.167.190.0.30.172.31.5.199 = INTEGER: true(2)

.. and if I wanted to get more than just one prefix, I could walk a 
whole /16 with, e.g.:

$ snmpwalk -v 2c -c $comm -m BGP4-MIB $rtr bgp4PathAttrBest.193.166
...