Re: Clarification required

Hi Rajiv,

        Thanks for the elabourate mail. Everything is very clearly 
explained. However, your mail fails to give reason for why the OID 
natConfAddrMapEntryType has to remain read-create. I have pointed out 
reasons why it can be changed to read-only and yet give out the relevant 
information to the user. Infact, in the natConfAddrMapTable every other 
attribute  needs to be read-create, but how do we specify the 
natConfAddrMapEntryType in the case of dynamic? Please give me an 
example for such a possibility.

        Please be kind enough to let me know reasons for why it has to 
remain a read-create OID. In my view: if it remains a read-create OID 
then the user is forced to set a value while creating the row, which 
will have to be rejected at the agent end, if it is specified as dynamic 
[NAT or NAPT] mapping.

Thanks and Regards,
Sam.

Rajiv Raghunarayan wrote:

>Hi Sam,
>
>A typical NAT config and usage would be as follows:
>
>1. Define the translations/address maps. E.g. local address: 
>   10.0.0.0/24, global address: 64.0.0.0/24 (ports may also be 
>   involved, but I've ignored it for simplicity).
>
>   This is done by the network administrator, based on the
>   addresses available/in use and the network configuration.
>   At this stage, depending on various factors (e.g. ratio of
>   internal hosts v/s available external addresses, future
>   expansion, accessibility necessary for hosts/servers etc.),
>   the network administrator also decides whether the mapping
>   must be static or dynamic, what type of NAT (basic, napt) 
>   needs to be used etc.
>
>2. Depending on the mapping type i.e. static/dynamic (and, of
>   course, implementation) BINDs are created in the BIND table 
>   either immediately or when the traffic flows from/to the 
>   addresses defined in the address map. 
>
>   The BINDs created are based off the address maps defined
>   earlier. E.g. 10.0.0.1 => 64.0.0.1, 10.0.0.2 => 64.0.0.2.
>
>   In case of static address maps, the BINDs are defined and
>   fixed at the time of the address map definition i.e. the
>   number of local address will be equal to the no. of 
>   external addresses and these will have one-to-one mapping
>   as defined above (again ignoring ports for simplicity).
>
>   In case of dynamic address maps, the BINDs are defined
>   only when the traffic flows. The number of local address 
>   needn't be (and usually aren't) same as the no. external
>   addresses. This is, therefore, a dynamic mapping.
>
>>From a MIB perspective, the natConfAddrMapTable represents
>the translation/address mapping definition (step #1 above).
>The entries in this table may be created via SNMP, or any
>other means (CLI, HTTP etc.). The actual BINDs (as created 
>in step #2 above) are represented by the natAddrBind and 
>natAddrPortBind tables in the MIB.
>
>-Rajiv.
>
>>"Sam K. Sankoorikal" wrote:
>>
>>Hi Rajiv,
>>
>>        Good Day!
>>
>>        I have gone through section 4.3 of the NAT-MIB . I quote the
>>section:
>>
>>"  -  Setting  the natConfStatus to 'active'(1) will enable
>>      nat on the interface. Note that the associated entries in the
>>      natConfAddrMapTable and natConfProtTable (if any) must also
>>      be made active.
>>   -  The Address Bind and Address-Port Table will have the entries
>>      created due to this nat configuration. A Management Station may
>>      also, if deemed necessary, create entries Address Bind or a
>>      Address-Port Bind entry and link those entries to the
>>appropriate
>>      address map configured. "
>>
>>The above section does not tell us the values to be set in case you
>>needed to create an entry in the natConfAddrMapTable. ie what value
>>would I have to set natConfAddrMapEntryType to go on and create an
>>entry
>>
>>NatConfAddrMapEntry ::= SEQUENCE {
>>    natConfAddrMapName             SnmpAdminString,
>>    natConfAddrMapIndex            Integer32,
>>    natConfAddrMapEntryType        INTEGER,
>>    natConfAddrMapDirection        INTEGER,
>>    natConfLocalAddrType           InetAddressType,
>>    natConfLocalAddrFrom           InetAddress,
>>    natConfLocalAddrTo             InetAddress,
>>    natConfLocalPortFrom           Integer32,
>>    natConfLocalPortTo             Integer32,
>>    natConfGlobalAddrType          InetAddressType,
>>    natConfGlobalAddrFrom          InetAddress,
>>    natConfGlobalAddrTo            InetAddress,
>>    natConfGlobalPortFrom          Integer32,
>>    natConfGlobalPortTo            Integer32,
>>    natConfProtocol                BITS,
>>    natConfAddrMapStorageType      StorageType,
>>    natConfAddrMapStatus           RowStatus
>>}
>>
>>natConfAddrMapEntryType OBJECT-TYPE
>>    SYNTAX  INTEGER {
>>                static (1),
>>                dynamic (2)
>>            }
>>    MAX-ACCESS  read-create
>>    STATUS      current
>>    DESCRIPTION
>>            "This config parameter can be used to set up static
>>             or dynamic address maps."
>>    ::= { natConfAddrMapEntry 3 }
>>
>>I also quote Rohits' input:
>>Static Address assignment
>>   In the case of static address assignment, there is one-to-one
>>address
>>   mapping for hosts between a private network address and an external
>>   network address for the lifetime of NAT operation.  Static address
>>   assignment ensures that NAT does not have to administer address
>>   management with session flows.
>>Dynamic Address assignment
>>   In this case, external addresses are assigned to private network
>>   hosts or vice versa, dynamically based on usage requirements and
>>   session flow determined heuristically by NAT. When the last session
>>   using an address binding is terminated, NAT would free the binding
>>so
>>   that the global address could be recycled for later use. The exact
>>   nature of address assignment is specific to individual NAT
>>   imp
>>lementations.
>>(The functionality has been described. More could be added on how we
>>would configure the same)
>>
>>Based on the above definition of dynamic NAT it seems that the
>>NatConfAddrMapEntry 's  which are dynamic are created on the fly, on a
>>need basis by the NAT module/protocol and can't be exactly specified
>>as dynamic and created by a user through SNMP. However if we wanted to
>>configure a Static NAT entry then that configuration could be created
>>by the user by specifying other [Direction, Addresses, Ports,
>>protocols] OID value other than the natConfAddrMapEntryType. This
>>value will be derived. Hence I think it would be clearer if the
>>natConfAddrMapEntryType were given a max access of read-only. This is
>>something which cannot be specified by the user. To tell more about
>>the dynamic entries I think by enabling NAT on an interface and
>>running a network application using NAT, then dynamic NAT entries
>>would be created. The same could be repeated for NAPT.
>>
>>natConfAddrMapEntryType OBJECT-TYPE
>>    SYNTAX  INTEGER {
>>                static (1),
>>                dynamic (2)
>>            }
>>    MAX-ACCESS  read-only
>>Thanks and Regards,
>>Sam.
>>
>>--
>> [ ]    Sam K. Sankoorikal.
>>        Home Net Solutions ,
>>        Wipro Technologies
>>        Ganapa Complex,
>>        #53/1 Hosur Rd Madivala,
>>        Bangalore, India 560068
>>        PBX:     +91 80 5502001 extn 3114
>>        [email protected]
>>
>>                           Name: Wipro_Disclaimer.txt
>>   Wipro_Disclaimer.txt    Type: Plain Text (text/plain)
>>                       Encoding: 7bit
>>
>