Subject: [NAT] Clarification reqd

From: "Sam K. Sankoorikal" <[email-masked]>
Date: Mon, 09 Dec 2002 21:33:04 +0530

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.

-- 
  Sam K. Sankoorikal.
  Home Net Solutions <http://www.wipro.com/homenet> ,
  Wipro Technologies <http://www.wipro.com>
  Ganapa Complex,
  #53/1 Hosur Rd Madivala,
  Bangalore, India 560068
  PBX:     +91 80 5502001 extn 3114
  [email-masked]

---

From: "Sam K. Sankoorikal" <[email-masked]>
Date: Wed, 11 Dec 2002 13:10:51 +0530

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. 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.

                        An associated problem with the 
natConfTable.natConfEntry.natConfAddrMapConfigName is that. This table 
decides the Index for the natConfAddrMapTable. 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. 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. Is there any other purpose in 
having it as a string ? Please highlight the purpose/advantages in 
having it as a string.

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:
>

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

---

From: "Sam K. Sankoorikal" <[email-masked]>
Date: Wed, 11 Dec 2002 13:10:51 +0530

Hi ,

Thanks and Regards,
Sam

---

From: Rajiv Raghunarayan <[email-masked]>
Date: Sun, 15 Dec 2002 13:26:04 +0530

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:
> 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

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.

> 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
> 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
> 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

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

-Rajiv.

---

From: Rajiv Raghunarayan <[email-masked]>
Date: Sun, 15 Dec 2002 13:26:04 +0530

Hi Sam,

-Rajiv.