Re: Clarification reqd

Hi Sam,

I'm not sure I completely follow your questions, but I've tried
to answer your questions (inline) based on what I understand 
(please correct me if I've misunderstood something).

"Sam K. Sankoorikal" wrote:
> 
> Hi ,
> 
>         I think I mixed up things in my previous mail. I'll try to frame
> it better:* *I have refered to * DEFVAL *as defined in RFC1212.
> 
>         Now consider the following scenario:
> 
>                         The natConfTable is used to enable NAT on the
> eth0. This is done by using the DEFVAL of ' 'H for the
> natConfAddrMapName while creating that row. Now if a snmpwalk is
> performed on the natConfAddrMapTable, even with just the "default index
> value" mapping rows can be returned. 

If an entry is created in the natConfTable and one queries the 
natConfAddrMapTable, entries needn't be returned. Basically, what 
I'm trying to say here is that creation of entries in the 
natConfTable doesn't result in automatic creation of entries in
the natConfAddrMapTable. One needs to explicitly create entries
in the latter.

A typical configuration process would be as follows:

Create generic address mapping entries in the natConfAddrMapTable.
Now when NAT needs to be enabled on a particular interface, create
an entry in the natConfTable and associate it with the appropriate
mapping from the natConfAddrMapTable (via natConfAddrMapConfigName).

> The returned entries are now
> returned with primary index as ' 'H and secondary index as the value of
> natConfAddrMapIndex( 1 .. 2147483647).
>                         Now here is the problem I see: Repeat the above
> steps for eth1.  ie Enable  NAT for eth1(Here also  natConfAddrMapName
> is specified as the DEFVAL). Now if a walk is performed on the
> natConfAddrMapTable there will be a problem in retuning the rows, as
> sorting based on the primary index and secondary index will not be
> possible. ie there could be two entries for each  The problem originated
> since the DEFVAL clause does not seem to provide a correct default.
> Ofcourse the user should have the understanding to use unique values for
> each entry created in the natConfTable. Please let me know your views on
> this and if the scenario is valid, a possible solution for the same.

Not sure I completely understand the scenario, but the basic 
assumption that creation of entries in natConfTable will result in
automatic creation of entries in the natConfAddrMapTable is, imho,
incorrect.

> 
>                         An associated problem with the
> natConfTable.natConfEntry.natConfAddrMapConfigName is that. This table
> decides the Index for the natConfAddrMapTable. 

It's the other way round. What value to be written into the
natConfAddrMapConfigName is decided by the index of 
natConfAddrMapTable i.e. natConfAddrMapName.

> Now, assuming that the
> two tables are tightly tied up, any change in the
> natConfTable.natConfEntry.natConfAddrMapConfigName  in the first table
> will result in changes in the second table. 

No. These two tables are linked, but I'd say loosely linked. Please,
correct me if I'm mistaken, but afaik the draft doesn't imply 
anywhere that changes in the natConfAddrMapConfigName must result 
in changes in the natConfAddrMapTable. If it does, perhaps a 
correction might be required..

> I dont believe this is a
> consistent thing to do. 
> Why can't the index be predecided when we know
> that the index is just to indicate to the Manager the interface to which
> the mapping belongs. The primary index in the natConfAddrMapTable could
> be the primary index of the natConfTable. 

The primary index of the natConfAddrMapTable is used to configure 
an address map. It doesn't tie this address map to any interface.

The index of the natConfTable is used to identify an interface
and associate a certain nat config with this interface (via
the natConfAddrMapConfigName). 

Note that via the existing mechanism one can tie more than one 
interface with the same NAT config without creating multiple
entries in the natConfAddrMapTable (which would be required
if one uses the ifIndex as the primary index of the table).

> Is there any other purpose in
> having it as a string ? Please highlight the purpose/advantages in
> having it as a string.

A number could've been used in place of the string, but the string 
just aids in better readability. 

-Rajiv.

> 
> Thanks and Regards,
> Sam
> 
> Sam K. Sankoorikal wrote:
> 
> > Hi Rajiv,
> >
> >         I have a specific query on the natConfAddrMapName[Seems to a
> > be a complex index]: Is there some convention[~default] to be followed
> > when using this index while returning a row of this table?
> >         This a scenario where the natConfAddrMapName may not be have
> > yet been given a name by any manager and NAT / NAPT is already enabled
> > on an interface. As a result, there are rows already present in this
> > table, based on mapping created on the fly by the NAT module, through
> > some UI configuration. Is it OK/Safe if the Agent decides to use a
> > name it finds convenient and thus be able to return to NAT mapping to
> > any manager querying it ?
> >
> > Some relate questions:
> >
> > 1. Does the agent also have to store the same value in the
> > "natConfTable.natConfEntry.natConfAddrMapConfigName".?
> >
> > 2. Can a Manager change only
> > natConfTable.natConfEntry.natConfAddrMapConfigName and what is the
> > effect on the natConfAddrMapEntry.natConfAddrMapName. This leads to an
> > inconsistent state in SNMP if left to the Manager.
> >
> >
> > Thanks and Regards,
> > Sam.
> >
> 
> _______________________________________________
> nat mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/nat