[Rack] Oddity on 188.8.131.52
jof at thejof.com
Mon Jun 18 14:53:22 PDT 2012
On Mon, Jun 18, 2012 at 2:38 PM, Danny O'Brien <danny at spesh.com> wrote:
> On Mon, Jun 18, 2012 at 2:19 PM, Ben Kochie <ben at nerp.net> wrote:
>> If we got a /24, we could eliminate our NAT. We could still firewall most
>> inbound traffic to noisebridge, but making NAT go away would make me happy.
>> As jof says, the real problem is our consumer network connectivity. It
>> would be very difficult to convince monkeybrains/sonic to let us do BGP.
> I think they might be the least hard to convince of all possible
> consumer services, but that might not be saying much :)
It's very true, they're awesome, local ISPs. We'd probably just have
to find the right people to get drunk and excite them about the
Still -- many consumer-oriented ISPs will not speak BGP nor allow you
to announce out your own space. The demand is so low, that it's just
not worth the larger more expensive routers closer to customers.
All that said -- this wouldn't stop us from tunneling. How that works
is like this:
- Get or share some colo space where we can get transit providers or
speak BGP. Access-oriented transit is relatively "free".
- Get N commodity internet connections from Sonic, Comcast,
Monkeybrains or whomever
-- Connect a router that can address each of these paths. Via VLANs or
lots of NICs.
- Plumb N static IPs in the colo space, not in the block-to-be routed.
- Static route paths to those N static IPs via each commodity path,
sourcing from the relevant source IP.
- Create tunnels from both the colo and Hackerspace ends of the tunnel endpoints
- Either bond, or operate equal-cost multipath routing across all of
The inside-the-tunnel IPs can now be anything we want (that can also
be sourced from the colo-end site). Plus, we'd get the added bonus of
aggregate bandwidth of many paths, even for the same flow (assuming
This is more or less what was driving the "noisebridge-public" SSID at
83c that handed out IPs in a public /24.
Bonus points for adding health monitoring to take down / bring up each
tunnel/transit path, or for monitoring effective throughput and
weighting the next-hop routings.
It's been done before, and could be easily setup at Noisebridge, but
would require the colo space, IP space, and some persistence.
More information about the Rack