Contact Us

Transcript for this video

This is Module 4, discussing the IP MIB.

For the IP MIB, we had two basic sections that we had to change.

We needed to add a fairly large number of new objects to match the new constructs that IPv6 supplied, things like prefixes and router advertisements.

These we decided to add in a version-independent manner.

We probably could have put them in a v6-specific manner as v4 does not really use a lot of them.

But we decided that they could be used for v4 if someone needed them for some future protocol if they came up with a particular use for them.

We also needed to go through the old objects and do the relatively standard thing and replace the indexes with the new constructs that we have described in RFC 4001.

We also took this opportunity to clean up some oddities in the whole scheme, in particular in the counters.

Some of the counters did not quite match up properly.

So we took this opportunity to tidy them up and try and make them regular and describe them quite completely.

In RFC 4293, we have three fairly general-purpose knobs that control sort of the entire set of a stack.

The first one is to enable or disable forwarding, so you can say that you do or you do not want forwarding for the entire stack.

We also have one to set limits on the packet lifetime.

This is either the “time to live field” or the hop count.

And lastly is one to set the period for fragment reassembly.

This particular knob only exists in IPv4, as IPv6 specifies it within the protocol itself.

So what do the tables actually look like?

There are some generalized tables.

There’s one for v4 and one for v6 that gives specific information about the protocol, how it is behaving, and gives you a little bit more control for that protocol itself.

Then there are two sets of statistics tables.

These are designed to have the same objects within each table, but to give you different granularity for the different tables.

So the system statistics table will give you information for the system as a whole, whereas the ifTable, or interface statistics table, will give you that information on a per-interface basis.

In theory, if you added up all the interfaces, you should sort of get to the system, but there are potential oddities, with interfaces that come and go, or other things such as that.

The Internet address table supplies information about the addresses that this particular system is using.

The Internet address translation table is essentially the old ARP type tables, or “net to media” tables, that allow you to translate from an IP address to a MAC address.

The scope zone index table gives you information about the various scopes that exist on this particular host.

The Internet address prefix table is something that may not turn out to be quite so useful as we hoped.

It allows you to specify a single prefix that is then used elsewhere in other tables.

In theory, this will allow you to have a smaller amount of total information, in practice it may not be quite as useful as we had hoped.

The default router table gives you information about the default routers that this particular host has learned about.

The router advertisement table provides information for actually a router rather than a host.

This is the information that would go into a router advertisement.

It probably really should have been in one of the router tables, but we thought it would be useful and it got in here, and by that time it was too late to move it.

The ICMP statistics table provides totals for the number of ICMP errors that you have seen.

These are all the ICMP errors that you have seen.

The next table, the ICMP message stats table provides per-ICMP type of error. So for each individual class of error, you would get a separate entry in the table.

The entries do not have to exist until they start getting numbers, but you do have to be able to return a zero in that case.

For the compliance and conformance statements, we tried to arrange the tables so that you could pick and choose what type of device you were building and only do those pieces of the tables that really mattered to you.

So for bandwidth type things, there are: less than 20 MB, 20 MB to 650 MB, and greater than 650 MB.

Realistically, most devices should be doing the last one at this point in time, but if you are doing a lower end device without quite so much horsepower as some of the others, you can pick and choose which chunks you want to do.

We also have functionally based compliance. So you can be a router, an IPv6-only device or an IPv4-only device, and you can pick and choose which of the tables you need to implement based on those particular items.

We did deprecate quite a large number of objects.

Basically all the objects that were defined in previous MIBs that we actually updated are now superseded and deprecated.

As part of actually providing a device, you will have to look over those and see which of those you may need to implement.

Your customers may have management systems that already do certain things, and therefore you may find yourself needing to actually implement some of the deprecated objects for those devices to work properly.

We did try and set it up so that you could use the same underlying code between the new objects and old objects.

So that in theory, all you’ll have is two separate method routines, or whatever type of method your SNMP engine uses to actually grab the data, but your actual underlying data itself can be the same.

This concludes Module 4.


Want to Know More?


Find more videos How to buy Contact an Expert