2012/10/5 Amos Jeffries <squid3@xxxxxxxxxxxxx>:
> On 5/10/2012 4:36 a.m., E.S. Rosenberg wrote:
>>
>> 2012/10/1 Amos Jeffries:
>>>
>>> On 01.10.2012 03:39, E.S. Rosenberg wrote:
>>>>
>>>> 2012/9/30 Amos Jeffries:
>>>>
>>>>> On 30/09/2012 12:43 p.m., Eliezer Croitoru wrote:
>>>>>>
>>>>>>
>>>>>> On 9/29/2012 9:38 PM, E.S. Rosenberg wrote:
>>>>>>>
>>>>>>>
>>>>>>> I have A, B and C with a potential for quite a few more (not
>>>>>>> necisarily ISPs but also browsing restrictions or lack thereof).
>>>>>>> I guess I over-simplified things a bit, but we have lots of user
>>>>>>> based
>>>>>>> stuff going on, in addition we also want to start capping bandwidth
>>>>>>> usage on a per user basis so that resources are shared more fairly
>>>>>>> etc.
>>>>>>> Regards,
>>>>>>> Eli
>>>>>>
>>>>>>
>>>>>>
>>>>>> Well still the only difference is that you will need to design the
>>>>>> acls
>>>>>> you are going to use.
>>>>>> are you using tproxy or intercept?
>>>>>> you can try by listing a of the things you want to implement and then
>>>>>> plan
>>>>>> the network design by that.
>>>>>>
>>>>>> if you have 6 ISP's for example you can put one proxy not cache at all
>>>>>> for
>>>>>> the interception and accounting stuff which is basically acls and
>>>>>> other
>>>>>> stuff.
>>>>>> then use cache_peers with 6 incoming ports that will decide the
>>>>>> outgoing
>>>>>> port by the incoming port.(just something in my mind).
>>>>>
>>>>>
>>>>>
>>>>> or a "OK tag=ISP-1" from the external ACL helper and a tag type ACL in
>>>>> tcp_outgoing_* to determine either outgoing IP or TOS marking.
>>>>>
>>>>> I recommend 3.2.1 or later for this type of thing though we did a lot
>>>>> of
>>>>> bug
>>>>> fixing and performance polishing of this type of config in 3.2.
>>>>>
>>>>>
>>>>>
>>>>>> if you have some ICAP service then put it somewhere in the
>>>>>> infrastructure
>>>>>> in a place that wont effect you delay pools etc.
>>>>>>
>>>>>> I dont remember about resources consumption by a no cache at all squid
>>>>>> but
>>>>>> it should be low.
>>>>>
>>>>>
>>>>>
>>>>> Squid uses a few MB base footprint and up to (usually under) 256KB per
>>>>> concurrent transaction. The rest is cached data.
>>>>>
>>>>>
>>>>>> I do remember you wanted somewhere to cache youtube etc..
>>>>>> I have a working solution for that and I'm working on
>>>>>> store_url_rewrite
>>>>>> which can benefit from this two.
>>>>>>
>>>>>> you can also add some captive portal that has user validation in it
>>>>>> for
>>>>>> wireless places ( I was working on a way to do it for transparent
>>>>>> proxy
>>>>>> like
>>>>>> in wifi-coffe shops that has agreement and other stuff like "prepaid
>>>>>> cap"
>>>>>> that is being used in cellular providers.
>>>>>>
>>>>>> just make a list of things you need\want to get from the network and
>>>>>> from
>>>>>> there the only question is how to put the whole puzzle together.
>>>>>>
>>>>>> Regards,
>>>>>> Elizer
>>>>>>
>>>>> Amos
>>>>
>>>>
>>>> Great.
>>>> So just to summarize:
>>>> - Reloading often is bad, use smartly structured ext_acls instead.
>>>>
>>>> As far as how we do it, we don't use tproxy, we have a class B for
>>>> ourselves so internally, so the user facing proxy that needs to handof
>>>> information about a forced plan because of some location does that
>>>> through the IP it presents to the parent.
>>>
>>>
>>> This is questionable practice. Does the information have to be passed as
>>> an
>>> IP or would using TOS values to mark the service type for particular
>>> handling work with your other infrastructure?
>>
>> Well this is what we need to do for one of our ISPs and I saw no
>> reason not to use the same technique internally, what's bad about
>> conveying that info like that?
>
>
> "questionable". IPv4s are running out, and how many does this one server
> consume?
Internally I have a /16 ("Class B") to work with and towards the ISP
we currently have a /29.
So far that is enough.
>
> It also limits the connection count since each IP is locked to one user who
> woudl be using not many ports out of the 64k that IP would otherwise make
> available.
I am not sure I follow.... I'd be using IP addresses to convey a
plan/ISP but lots of users would be "using" the same IP.
>
>
>> Also I don't see any ACL that in turn allows me to do stuff on the
>> parent based on the TOS set by the child cache...
>
>
> That is a probem. I was of the understanding this was a single proxy layer
> with upstream routes. The OS routing systems should be fully capable of
> receiving TOS values from Squid and routing traffic based on them.
Ah, no there are 2 layers of proxies, 1 layer facing the user that is
supposed to do authentication etc. and basic caching and a second
layer facing the ISPs that is supposed to be specialized in caching,
connected to AV server, do delay pools and route users to different
ISPs/plans@ISPs based on username or on the IP presented by the child
caches.
Regards,
Eli
>
> Amos
