Re: Clarification required

Rajiv,

            Well there seems to be some specific cases, as you pointed 
out, where this can to be set to dynamic/static as the case maybe. As 
for your second mail  quoted below:


" I'm not sure if this is cause for confusion, but just in case..
The natConfAddrMapEntryType reflects that static/dynamic nature
of entries in the natAddr*Bind tables, and *not* the nature of
entries in the natConfAddrMapTable. 

-Rajiv."

            Here it seems we are running into a loop. Does this again 
mean that based on what entries we have in the natAddrBindTable the 
value of natConfAddrMapEntryType is decided. But I guess we already have 
natAddrBindType - to decide what types of NatAddrBindEntry are present 
there. Shouldn't it be that the Bind table uses the values in the 
 natConfAddrMapEntryType to decide what type of entry it must hold there??


Thanks for the clarification,
Sam.

Rajiv Raghunarayan wrote:

>Hi Sam,
>
>As we've discussed below, a network admin specifies the address map in the
>natConfAddrMapTable, and at the same time also determines whether this
>needs to be a static map or a dynamic one. A simple rule for this could be
>- if the no. of internal & external addresses is equal use static map,
>else dynamic. And this could potentially be employed and the object
>implemented as read-only by certain implementations. But this certainly
>doesn't address all cases e.g. a customer might want to use dynamic map
>inspite of equal internal & external addr. count. The mib definition would
>need to account for all such cases too. Hence, the natConfAddrMapEntryType
>is a read-create object.
>
>-Rajiv.
>
>On Mon, 2 Dec 2002, Sam K. Sankoorikal wrote:
>
>>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
>>>>
>>
>>
>>
>
>