On 12/7/06, John Doe <phoenixoverride(a)gmail.com> wrote:
>
> 85.234.128.0/20
> 85.234.144.54/31
> should handle the issue. Betacommand
>
> On 12/7/06, Luna <lunasantin(a)gmail.com> wrote:
> >
> > Oooh, good. Didn't know you subscribed to this list. :) Essjay's
> > original block was on 85.234.128.0/19 , the address we seem to be
> > friends with is 85.234.144.53
> >
> > On 12/7/06, John Doe < phoenixoverride(a)gmail.com> wrote:
> > >
> > > I can do the blocks of a range if you tell me what should NOT be
> > > blocked I can nail the rangeblock just right. Betacommand
> > >
> >
So doing the CIDR blocks is the only way?
To be pedantic and fully complete, we'd want:
85.234.128.0/20
85.234.144.0/27
85.234.144.32/28
85.234.144.48/30
85.234.144.52/32
== gap for unblockee at 85.234.144.53/32
85.234.144.54/31
85.234.144.56/29
85.234.144.64/26
85.234.144.128/25
85.234.145.0/24
85.234.146.0/23
85.234.148.0/22
85.234.152.0/21
Unless I missed a bit or bits somewhere doing this in head and on fingers.
This seems like we should automate something; either a netblock minus
exceptions interface tool to autogen the CIDR blocks from a top range plus
some exceptions, or adding in an explicit "unblock this IP" override and
have any CIDR block range lookup check the unblock override before returning
blocked or not.
Nobody does Cisco ACLs or BGP routing this way the hard way if they can help
it... and our admins by and large aren't network geeks.
--
-george william herbert
george.herbert(a)gmail.com
