[125546] in North American Network Operators' Group
Re: Rate of growth on IPv6 not fast enough?
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Mon Apr 19 14:08:56 2010
Date: Mon, 19 Apr 2010 11:07:19 -0700
From: Leo Bicknell <bicknell@ufp.org>
To: NANOG list <nanog@nanog.org>
Mail-Followup-To: NANOG list <nanog@nanog.org>
In-Reply-To: <4BCC9157.9040507@bryanfields.net>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--G4iJoqBmSsgzjUCe
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In a message written on Mon, Apr 19, 2010 at 01:22:31PM -0400, Bryan Fields=
wrote:
> Right now I'm using 42 translation entries in my nat table. Each entry t=
akes
> up 312 bytes of FIB memory, which is ~12.7 Kib of data in the FIB. Mutip=
ly
> this by 250k users and we have 3,124,237 KiB of FIB entries, or 3.1 GiB. =
This
> is not running any PtP programs or really hitting the network, I'm just
> browsing the web and typing this email to you.
[snip]
> Now things get fun when I turn on my torrent program, average
> number of translations is at 3500 per person (during a virus outbreak or =
other
> network event), we'll need a pool of 27k public IP's and 254 GiB of ram to
> store the NAT tables. This would be a /17 of IP space just to NAT 250k
> private users!
There are a few problems with your data....
I know of no platform that does hardware NAT. Rather, NAT is a CPU
function. While this is another interesting scaling issue, it means
this data is not going in the FIB (hardware forwarding database),
but rather is stored in a CPU accessible database.
It's not that you need 3.1G/254G of memory in the FIB (which would
be expensive) but rather that you need it in relatively cheap DRAM.
Even if use your larger memory number of 254G that's only $10-15k
of RAM cost these days, hardly a deal breaker. The FIB would hold
only one entry for the /17 (or similar) pointing it to the CPU.
Secondly, you're playing to both extremes. Yes, the point to point
user will use 3500 entries and grandma checking e-mail may use 42
entries. Not everyone will run a point to point client, and not
everyone will be grandma. Using an average is a much better first
start. I suspect though the percentage of users using a point to
point client is small though, and thus drives the average number
even lower.
So, 3500 + 42 / 2 =3D 1751 entries on average per person.
250,000 users * 1751 entries * 312 bytes/entry =3D ~136G of data.
250,000 users * 1751 entries / 64000 ports/IP =3D 6939 IP's.
So a /19 provides headroom. 10 servers, each with 16G of RAM
(160G total) could do the job with headroom.
Not all users will be active at the same time, so 100k per user
probably translates into a 1Mbps/sec rate, given the old 10:1 rule on
end users.
250,000 users * 100,000 bytes/sec =3D ~186Gigabits/sec. Humm,
10 servers won't do that (18Gbps/sec per server of NAT, no way!).
40 servers though would be 4.65Gbps per box, which with 10GE seems
reasonable. But that also means each one only needs 1/4th the RAM
from above.
In summary, to NAT 250,000 users:
40 servers, each with:
CPU capable of NATing 4.65Gbps
4-8Gb of memory
2x10GE interfaces
A /19 of address space.
I think a server like that could be had for $10k each, easy. So
400k of servers, depreciated over 3 years, divided by 250,000 users:
$0.53 per user per YEAR. Or, $0.04 per month per user. Even selling
$20 packages ISP's should be able to absorb four cents per user.
NAT scales just fine. I find that quite unfortunate, personally,
but I don't think there's a problem with the technology or economics.
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
--G4iJoqBmSsgzjUCe
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.13 (FreeBSD)
iQIVAwUBS8yb17N3O8aJIdTMAQLgCQ/+PIyfFvnhRwwkUDG55YN0paudd3o/Qtxf
KEITN+mvrTS24Opow0ZmMmeHNJ37MHshcrx5ou0fn+rVUOtzze7kbbZsrZMdlBVM
CQiYCqLeLpRqDVQ4lw39ZU+wjbJwPbRDb1zWi7HkQYj6NYBr2s817Gf1ghEVR9VR
lGiav+ZT1nhRQcGRQZHHqRHPmpjrqGbVhOpY9Ts6WPxM+wGw6bDXH8KAsi6vYgIb
lXVNeejTflC5FUmLjhdyt1t3PN/oMOxfOIZCWuXD4/rphHgEMV37unYgpd2HWgT7
Y12jRCIbARIVQSO0yL50H2ovYwB11ALbpT24cG3nhuqrO3g2xvJ1J3m89yeoQ/Ak
TYxqUvX5dIA4/QQWKFTjQk/VzSsVOWlUsy9xyl/2Yxq83sEKEugoS6juWtILetGE
brJTDamlpYsdw3FQLGSa2sseXr0PKEs5dAHP1kSF2oJz20f5AjXM4m+luG0AJMTr
iNCnQqyU7fyGuv4i2q7l8ow8fWugi8z1Ny2l0keLZ1lgUCSR8Pamd/of/U4znz3h
WrWtseOjCa5e5HicjI6xuR5fuwxbwFJgij8U5yNTkazcTTnNXPdpMlFJ9NniOpqg
qpx04ya3S+/M2KV41zyh2io7tP+FQJnQM8dKwimI6I0gcyH5IcWE25e7jBHHmTV4
NcCfONAAvyo=
=Sypx
-----END PGP SIGNATURE-----
--G4iJoqBmSsgzjUCe--
