Re: Clarification required
Rajiv Raghunarayan <[email protected]> Mon, 02 Dec 2002 12:42:06 +0530
| Newsgroups | gmane.ietf.nat |
|---|---|
| Organization | Cisco Systems Inc. |
| Message-ID | <[email protected]> |
Hi Sam,
One comment inline..
"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.
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.
>
> 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
> >>
> >
>
> _______________________________________________
> nat mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/nat