> erm, no. A more flexible and general solution would be to add a
> destination lookup table as well as source and masq, and have the
> ability to look up by hashing the source address and port from inbound
> packets into the destination lookup table.
Yes, I agree that dest table will be useful but why to add
additional tables. We don't need each protocol to use it's own table.
Let it use it's own keys for ip_masq_m_tab and ip_masq_s_tab. I again
return to my example where connections are created outside firewall
to virtual web server for example and then redirected to local web
servers. If we add additional dest lookup table we will faster
create entries and search entries by daddr&dport from inbound packets
but we will spend too much time in ip_masq_unhash - we must unlink
entry from each table but all entries in ip_masq_m_tab and
ip_masq_s_tab are hashed by maddr/mport and saddr/sport, i.e. they
are all linked on same row. For example if we receive 1000 connections
per second to our virtual server and we serve these connections for 10
seconds and time-wait 120 sec we have 1000*(10+120) entries. Search in
dtable will be fast but we must unhash 1000 entries per second searching
in ip_masq_m_tab and ip_masq_s_tab where we must remove 1 entry from
130000 => we must compare data for 65000 average per second (expect
newly created connections in top of list followed by old connections,
i.e. 65000-130000). So, we need faster access not just when searching
in dest table (if we decide to add such table) but faster access to
other tables. Yes, we don't have 65000 times faster access but for
short connections where we have to transmit 50KB for example (assuming
acks and 1500 bytes per packet) we have to:
- create entry (faster)
- receive and lookup for ~70 packets (faster)
- remove entry (slow - search 65000 entries)
I thing using IP_MASQ_F_MPORT as flag what to use as key for
these two tables allows both normal and reverse masq connections to
be handled faster for these operations:
- add entry to table (ip_masq_hash)
- lookup by values from inbound packets (__ip_masq_in_get and
__ip_masq_out_get)
- remove entry from table (ip_masq_unhash)
So, I thing:
- we don't need additional tables (more than 2) - we need proper
keys
- we need fast lookup to any table for any entry
- normal and reverse connections can coexist in all
tables (ip_masq_m_tab and ip_masq_s_tab) and to have
fast any kind of access (create/lookup by data/remove)
- any protocol can use these 2 tables if IP_MASQ_F_MPORT is
used (set or unset), i.e. if ip_masq_new() is used.
- IP_MASQ_F_MPORT distinguishes between normal and reverse
connections, i.e. if daddr/dport are useful
- we can ignore IP_MASQ_F_MPORT for TCP and always to hash
using daddr and dport (even for normal masq connections)
but this is another variant (may be not good).
- yes, we can skip this first check in ip_masq_in_get for
entries with IP_MASQ_F_MPORT flag set if mport is in
PORT_MASQ_BEGIN..PORT_MASQ_END range (to be done)
J. Anastasov
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/