|On Thu, 20 Jun 2002 20:19:43 -0400
|Ramin Alidousti <[EMAIL PROTECTED]> wrote
| about Re: Completely NAT an ISP: A practical possibility?:
> Do you guys do DNAT too? I mean do you let the costomers run services?
Nope. Only SNAT is used to route the client pool (with the same media provider)
to the appropriate ISP.
> Who assigns IP's to them?
They used DHCP with ADSL ( I said there were some dial-ups but I was mistaken, all use
ADSL now)
> The content providers? How do you sync up with them for the DNAT?
They sync up for SNAT. They have to authenticate via Web (before the firewall/router
to ISP),
after that a some rules are added automagically to the firewall by a third interface.
Since all use ADSL accounting can be done by crossing (ADSL modem ID,Dynamic IP, time,
logs).
/------- Web Auth-v
client pool - |
\ ----- Firewall/Router----------(ISP pool)
\------------ "
\------------- "
> The whole NAT solution between the medium provider
> and the content provider is still a bit vague to me, especially when you
> sell static IP's to the customers...
In fact there are no more static addresses, I mixed up some scenarios in my
previous e-mails ;o)
> > What we did was to use a priority queue and hashtables to implement full
> > NAT to FTP and H.323 only (our immediate needs by then).
>
> Feel free to elaborate on this priority queue/hashtables implementation
> to solve FTP/H.323 problem. Sounds like an extendable thing for other
> unfriendly protocols.
We dropped that solution because it was focused in kernel 2.2 and iproute2.
Basically we had a priority queue acting as a self-made conntrack module.
We have chosen in favour of a priority queue "statistically"
betting in better performance, supposing client traffic would be in bursts
during short periods of time. That proved to be more efficient than using a hashtable
as the top level indexing structure.
I do not know in what data structures the current conntrack/filtering is based,
did not have the time (and the need!) to check it out. For the time being I trust
is is fast/smart enough. If it becomes a bottleneck, then we'll see !
best regards
Senra
--
Rodrigo Senra
MSc Computer Engineer (GPr Sistemas Ltda) [EMAIL PROTECTED]
http://www.ic.unicamp.br/~921234 (LinUxer 217.243) (ICQ 114477550)
