ARP and NetToMedia
Daniel SECCI
Does anyone know the difference between the at (address translation)
table and the ipNetToMedia table (both in RFC1213) ?
Thanks,
Daniel
C. M. Heard/VVNET, Inc.
>
> Does anyone know the difference between the at (address translation)
> table and the ipNetToMedia table (both in RFC1213) ?
They convey *almost* the same information, but in a different form. The
main difference is conceptual (what data type is the network address).
Here is an example of an atTable entry, as reported by snmpwalk:
at.atTable.atEntry.atIfIndex.1.1.10.0.0.1 = 1
at.atTable.atEntry.atPhysAddress.1.1.10.0.0.1 = Hex: 00 A0 24 7A 93 AF
at.atTable.atEntry.atNetAddress.1.1.10.0.0.1 = IpAddress: 10.0.0.1
Here is the same ARP cache entry, shown as it is represented in the
ipNetToMediaTable:
ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaIfIndex.1.10.0.0.1 = 1
ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaPhysAddress.1.10.0.0.1 =
Hex: 00 A0 24 7A 93 AF
ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaNetAddress.1.10.0.0.1 =
IpAddress: 10.0.0.1
ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaType.1.10.0.0.1 =
dynamic(3)
One obvious difference is that the ipNetToMediaTable has the extra entry
ipNetToMediaType, whose value is static(4), dynamic(3), invalid(2), or
other(1). This permits one to distinguish between transient and permanent
ARP cache entries, which are supported by some implementations. It also
allows invalidated mappings which remain in the table to be marked. The
atTable also has the latter feature, but does so by using the convention
that an invalidated mapping is one with a physical address of zero length.
However, the conceptually more important difference between these tables is
in the data type used to represent the network address object. The atTable
was intended to work with protocols other than IP, and it represents the
network address using the now-obsolete NetworkAddress type. The
ipNetToMediaTable is IPv4-specific, so it represents the network address
using the ipAddress type. Notice the extra '1' which precedes the IP
address 10.0.0.1 in the atTable index components shown above. This is the
hallmark of the NetworkAddress type and is the visible distinction between
it and the IpAddress type.
RFC 1155 defined NetworkAddress as a CHOICE type with the intent that it
would be able to represent any kind of network address which was ever
defined. This presumed that new application-wide types with different
ASN.1 tags would be instroduced into the SMI as the need arose for new
network address types. However, the SNMP elements of procedure require
that a PDU containing unknown types ASN.1 tags be discarded and flagged
as an ASN.1 parse error -- which means that introducing new types would
obsolete deployed implementations. It soon became clear that new types
really could not be added -- one defines textual conventions instead.
So no CHOICEs other than ipAddress were ever defined for NetworkAddress,
and the type was deprecated in SMIv1 and removed from SMIv2. The atTable
was deprecated as a result, and a rule was made that each protocol which
needed its functionality would define its own table. Thus was born the
ipNetToMediaTable.
As a practical matter, in an IPv4-only ARP implementation it is relatively
easy to implement both the atTable and the ipNetToMediaTable, and it is
very commonly done.
Mike
--
C. M. Heard/VVNET, Inc.
he...@vvnet.com
Daniel SECCI
atTable and in the ipNetToMediaTable. So if atTable is deprecated it
would be better to use ipNetToMediaTable for IP based-networks and
don't worry anymore about the atTable. Am I right ?
This is very important to me because I am involved in some kind of network
discovery project and I need the ARP table to gather information.
Using ipNetToMediaTable and forgeting atTable would save much discovery
time (I'm actually using both).
Thanks again
Daniel
C. M. Heard/VVNET, Inc. <he...@vvnet.com> wrote in message
news:379f4b00$0$2...@nntp1.ba.best.com...
C. M. Heard/VVNET, Inc.
>Thanks for your answer. If I resume, I should find the same data in the
>atTable and in the ipNetToMediaTable. So if atTable is deprecated it
>would be better to use ipNetToMediaTable for IP based-networks and
>don't worry anymore about the atTable. Am I right ?
>This is very important to me because I am involved in some kind of network
>discovery project and I need the ARP table to gather information.
>Using ipNetToMediaTable and forgeting atTable would save much discovery
>time (I'm actually using both).
I think your conclusion is correct: there is no need for a management
application to retrieve both the atTable and the ipNetToMediaTable.
The atTable is deprecated, and anyway there is more information in
the ipNetToMediaTable.
Ed
I have just implemented both of those tables on one of our products
(telecom device - doesn't do much with IP except SNMP management).
But I have no idea what they are really for and whether anyone
actually uses them, and for what?
If the arp table is deprecated, shouldn't I be able to leave it out of
my implementation? But I put it in because it said it was mandatory in
MIB 2. (I'm doing SNMPv1)
Also I notice that if I really leave these things read/write (as in
the MIB), its possible to use the SNMP interface to hose the ethernet
connection or something, cutting the device off from further SNMP
management!!
I had a similar problem with the ethernet in the ifTable. If I let the
user change the AdminStatus to down, then the device was cut off from
further SNMP management and actually had to be rebooted! But of a
bummer for telecom equipment, eh?
So what is the general practice with these types of tables? Do I give
the user enough rope to hang himself, or do I defy the MIB and make
these things read-only?
Ed
C. M. Heard/VVNET, Inc.
>Thanks for all the info!!
>
>I have just implemented both of those tables on one of our products
>(telecom device - doesn't do much with IP except SNMP management).
The same is true of the product I'm working on.
>But I have no idea what they are really for and whether anyone
>actually uses them, and for what?
The ipNetToMediaTable and atTable allow a management application to
observe (and in some cases to modify) the contents of the ARP cache.
>If the arp table is deprecated, shouldn't I be able to leave it out of
>my implementation? But I put it in because it said it was mandatory in
>MIB 2. (I'm doing SNMPv1)
Let's be careful with terminology. I'm not sure whether by "arp table"
you mean the ARP cache itself, or the SNMP managed objects which represent
its contents.
An ARP cache is _mandatory_ in order for IP over ethernet to work properly,
quite independently of whether one's box is or is not SNMP managed.
As for the managed objects, the atTable is deprecated, but the
ipNetToMediaTable is current. It is included in RFC 2011, which
is the MIB-II IP group (less the ipRouteTable) translated into SMIv2.
As to whether you can leave the atTable out of your implementation --
that depends on whether or not the management apps with which you wish
to interoperate require it. The answer is that they probably do not;
but if you are not sure, you might as well go ahead and implement it.
In most cases it does not cost much extra to do so if you have already
decided to implement the ipNetToMediaTable.
>Also I notice that if I really leave these things read/write (as in
>the MIB), its possible to use the SNMP interface to hose the ethernet
>connection or something, cutting the device off from further SNMP
>management!!
>
>I had a similar problem with the ethernet in the ifTable. If I let the
>user change the AdminStatus to down, then the device was cut off from
>further SNMP management and actually had to be rebooted! But of a
>bummer for telecom equipment, eh?
>
>So what is the general practice with these types of tables? Do I give
>the user enough rope to hang himself, or do I defy the MIB and make
>these things read-only?
I chose to implement atTable and ipNetToMediaTable as read-only tables
for precisely the reasons you mentioned. The box in question is supposed
to run unattended, and it has but one ethernet link as its means of
control. There is the potential for much harm (and as far as I can tell
very limited or no good) if these tables are writeable. I have also
implemented ifAdminStatus for the ethernet link as read-only.
In addition, I elected not to implement the obsolete ipRouteTable since
the IP implementation that is being instrumented supports multiple default
routes (and multiple routes to the same host with different TOS values),
which that table cannot represent. I have instead implemented the
ipCidrRouteTable from RFC 2096 in my agent, but the implementation supports
read access only (for the same reasons that atTable and ipNetToMediaTable
are read-only).
From what I have been able to find out on the web, it appears to be
fairly common to make atTable, ipNetToMediaTable, and ipRouteTable
read-only (I have not been able to find out about ipCidrRouteTable
implementations other than my own). Note that such implementations
cannot claim compliance to the conformance statements in RFCs 2011
and 2096, nor can they claim conformance to MIB-II.
It is my opinion that the conformance statements should be changed to
allow MIN-ACCESS of read-only for all these tables. That is already
the case for ifAdminStatus in RFC 2233 (that RFC contains the updated
version of the MIB-II interfaces group). When RFCs 2011 and 2096 are
up for advancement, I shall make my views known and see if I can
convince the WG that such a change is desirable.
don provan
but they made some mistakes and replaced it with the NetToMedia table.
They kept the old table for backwards compatibility. In theory, a
discovery mechanism would need to check both tables in order to handle
systems so old that they were implemented before NetToMedia was added,
but in practice I doubt you'll miss anything significant.
In response to Ed's question: "So what is the general practice with
these types of tables? Do I give the user enough rope to hang
himself, or do I defy the MIB and make these things read-only?"
General practice is to make them read-only. This isn't a
violation of the MIB since defining a variable read/write does
not require that a node actually grant write access to any SNMP
community. Technically, the variable is read/write, but with a
hardcoded administrative policy forbidding anyone setting it.
-don provan
dpr...@home.com
dper...@snmpinfo.com
When you write a MIB module in SMIv2 format, you specify in
the MAX-ACCESS clause the architectually maximum access for
an object.
The meaning of the ACCESS clause in SMIv1 was ambiguous, thus, it
was replaced by the MAX-ACCESS clause in SMIv2.
On Mon, 2 Aug 1999, Bryan wrote:
> don provan <dpr...@home.com> wrote:
>
> : General practice is to make them read-only. This isn't a
> : violation of the MIB since defining a variable read/write does
> : not require that a node actually grant write access to any SNMP
> : community. Technically, the variable is read/write, but with a
> : hardcoded administrative policy forbidding anyone setting it.
>
> while technically true, I'm not convinced its the best practice.
>
> imagine the manager implications of this: you mark a certain table
> read/write; and that could mean to the mgr app that some textfields
> are editable. this indicates to the user that there are -some- ways
> of editing and saving those values remotely. when it doesn't work and
> doesn't work and [...], the user may spend a lot of time trying to
> figure out what he did wrong; when in fact, he did NOTHING wrong - the
> agent was actually broken.
>
> if the total absolute access (under any condition at all) is
> read-only, I have a slight problem marking such a table 'read/write'.
>
> --
> Bryan, http://www.Grateful.Net - Linux/Web-based Network Management
> ->->-> to email me, you must hunt the WUMPUS and kill it.
>
Regards,
/david t. perkins
Ed
Does that mean that the MAX-ACCESS would be read only? Or that the
MAX-ACCESS is R/W and there is some other clause to specify the actual
access?
Is it true that even if I have an SNMPv1 implementation I can use
SMIv2 to distribute my enterprise mib information to customers?
Should I?
Thanks!
Ed
dper...@snmpinfo.com
One uses either or both of data sheets and agent capabilities to
specify what you actually implement in an agent.
At this time, you should write all of your MIB modules in the SMIv2
format. If you have MIB tools that take only MIB modules in SMIv1
format, then you can use conversion tools to create them from
the SMIv2 format MIB modules. Going the otherway is not possible.
What protocol you use (either SNMPv1, SNMPv2c, or SNMPv3) is
independent in all cases except for objects with the Counter64
data type, since it is not supported in the SNMPv1 protocol.
Regards,
/david t. perkins