Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 21 Mar 2013 09:25:16 +0100
From:      =?ISO-8859-1?Q?Ermal_Lu=E7i?= <eri@freebsd.org>
To:        Mark D <markd-freebsd-net@bushwire.net>
Cc:        freebsd-net <freebsd-net@freebsd.org>
Subject:   Re: Best way for an app to accept traffic on 30,000+ interfaces?
Message-ID:  <CAPBZQG2eZ3C68HaAPRUehBJ62L%2B87-LdLRrMRkzj=-09dHKrYA@mail.gmail.com>
In-Reply-To: <20130321005959.98706.qmail@f5-external.bushwire.net>
References:  <20130321005959.98706.qmail@f5-external.bushwire.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 21, 2013 at 1:59 AM, Mark D <markd-freebsd-net@bushwire.net>wrote:

> (Hopefully this isn't too out-of-scope for this list..)
>
> I have an application in mind that I'd like to have accept/respond to
> UDP queries sent to perhaps 30K contiguous IP addresses (most likely
> IPV6 addresses because such ranges are easy to come by, but
> conceptually ipv4 as well).
>
> This would all be on a small number of FBSD instances.
>
> Though it could be done, I don't really want to create 30K interfaces
> and have the application bind 30K sockets as it's not clear if that
> will scale if I try an address range that expands to, say, 1M IPs
> wide.
>
> This address range would be internet-facing and responding to random
> remote clients.
>
> My first thought is to use SOCK_RAW in much the same way that natd
> does - at least to receive the traffic.
>
> Is that a sensible and viable approach or is there a better/easier
> way?
>
>
> Mark.
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>


How about firing up one of the firewall/pfil(9) consumers like (ipfw/pf)
and adding rules to redirect traffic to a socket bound on loopback?

-- 
Ermal



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPBZQG2eZ3C68HaAPRUehBJ62L%2B87-LdLRrMRkzj=-09dHKrYA>