search

inevity / lusca-cache

Automatically exported from code.google.com/p/lusca-cache
0 stars 0 forks source link

sibling cache peering with tproxy enabled cache doesn't work correctly #48

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
A tproxy cache cluster (eg behind WCCPv2) can't peer.

The issue stems from the forwarding logic creating source address spoofed
sockets to destinations that are inside the cluster. Since the WCCPv2
router won't redirect packets with an origin of the proxy MAC (at least for
L2 peering), source spoofed packets go out and are routed normally. The
packets back from the destination peer have a remote end of the spoofed IP,
and are instead sent to teh original client rather than the proxy.

The forwarding logic needs to be taught to optionally enable tproxy source
spoofing on connections based on a peer flag.

Just for completeness - tproxy'ed connections to a upstream or peer proxy
which is -outside- of the WCCPv2 tproxy cluster work fine.

Original issue reported on code.google.com by adrian.c...@gmail.com on 27 Jul 2009 at 4:45

GoogleCodeExporter commented 9 years ago 
Revision r14249 attempts to address this. It adds "no-tproxy" to the cache_peer
configuration which disables client IP spoofing on the request. It also 
disables the
tproxy check for idle pconn's open to that peer.

Original comment by adrian.c...@gmail.com on 27 Jul 2009 at 4:47

GoogleCodeExporter commented 9 years ago 
This is working just fine in production. Update the documentation.

Original comment by adrian.c...@gmail.com on 29 Jul 2009 at 1:31

GoogleCodeExporter commented 9 years ago 
partially documented in a new feature wiki page.

Original comment by adrian.c...@gmail.com on 11 Sep 2009 at 11:14