Re: Clarification required

Rajiv Raghunarayan <[email protected]> Sat, 30 Nov 2002 18:01:19 +0530
Newsgroups gmane.ietf.nat
Organization Cisco Systems Inc.
Message-ID <[email protected]>
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