Cisco policy routing can use source IP address for deciding to pass
traffic to the cache engine. The cache engine, normaly can be
configured to exempt destination. I believe that this fixes both
issues. Expecting the customer to be able to have a clue to
go to a www page is a bit much, tho. Some customers have setup
IP based authentication on their NT server, but can't figure out how
to configure SLL which wouldn't be cached, and would be more secure.
The burden of making this work is on the cache operator. Also it turns
out that the sites with the most problems with the cache are the ones
paying the least money for service. Its hard to feel very sorry for
a $20/month dialup customer, who is connecting to his coporate site
with a broken NT server.
If customers are using proxy's that break, its easy enough for them
to speak ICP, and still get the same operational conditions, as far
as the ISP side is concerned.
As far as the asmetric routing issue, the traffic INSIDE the ISP isn't
asmetric, and shouldn't need to be cached. I don't really see the
problem here. (But it could be me.)
Cisco policy routing can use source IP address for deciding to pass
traffic to the cache engine. The cache engine, normaly can be
configured to exempt destination. I believe that this fixes both
issues. Expecting the customer to be able to have a clue to
go to a www page is a bit much, tho. Some customers have setup
I find it ridiculous to suggest that an ACL be built and modified for each
and every "broken" thing you find. I wouldn't be surprised if the
resources necessary to keep this up - especially considering the potential
customer dissatisfaction it *will* cause - outweighs the benifit of the cache.
IP based authentication on their NT server, but can't figure out how
to configure SLL which wouldn't be cached, and would be more secure.
The burden of making this work is on the cache operator. Also it turns
out that the sites with the most problems with the cache are the ones
paying the least money for service. Its hard to feel very sorry for
a $20/month dialup customer, who is connecting to his coporate site
with a broken NT server.
If you are just now figuring out that there are users who are clueless on
the Internet, you're way behind the curve. If you figured this out a long
time ago and have simply dismissed those users - even the $20/mo dialup
customers - as "hard to feel very sorry for", then I'm surprised you are
still in business.
I give all of my users transit to their desired destination when the pay me
for it. Not just those cluefull enough to configure exceptions to the
proxy services I have decided to ram down their throat - without their
foreknowledge or consent.
You are, of course, welcome to do as you please on your network.
Jeremy Porter, Freeside Communications, Inc. jerry@fc.net
TTFN,
patrick
Uh, watch out, there are packet flow descriptions here. I'm sorry to
post something non-legal-related and non-inflammatory. If there's a
better list for technical issues, someone please point me at it :-)...
As far as the asmetric routing issue, the traffic INSIDE the ISP isn't
asmetric, and shouldn't need to be cached. I don't really see the
problem here. (But it could be me.)
That's true but only depending on how you look at it. If the client and
server are in the same IGP there is probably no benefit to be had from
transparent caching -- though replication and optimal redirection would
still have a place, at least in the larger IGP's.
But if one end of the connection is outside the IGP (and it doesn't matter
whether this end is the client or the server), and if the IGP has multiple
border gateways, then hot potato routing really screws you since the two
connections inside the TCP stream can potentially take different paths.
If a stream is going to be intercepted, it must be by a device which sits
in the path of both connections, since the sequence numbers of a connection
are used in the ACK fields of the other connection. If you can do your
interception in your customer's "tail" (the part of the customer's data
path where all ingress and egress still uses the same links/routers) you're
OK. But if you're sending a customer's segments out one path, which is
intercepted by one device, and the ACKs or other inbound segments come in
via some other path, which is not intercepted or is intercepted by some
different device, then you are pretty much screwed.(*)
This is one reason out of several why transparent caching is an access side
issue, and why the server side caching has to be done with something more
robust like replication and redirection.
[ (*) yes I know the two devices can synch their sequence numbers with a back
channel, or use predictable ones, but that slope is so slippery that it may
as well be paved with vaseline -- let's just not go there, OK? ]