Yeah, we started building this FAQ here as well: http://2pintsoftware.com/2psfaqs/
Covers most things, but not the MC bit, might add that. //A From: [email protected] [mailto:[email protected]] On Behalf Of Jason Wallace Sent: den 19 december 2014 18:45 To: [email protected] Subject: Re: [mssms] PeerDisc QQ So I have seen on a customer who has switches configured to prevent MC. I really had never pulled the thing apart that much as until this week it always just worked. It would likely be too much hassle as you said to extend this across multiple subnets On 19 Dec 2014, at 17:41, Andreas Hammarskjöld <[email protected]<mailto:[email protected]>> wrote: Yeah, its MC and not BC. So in theory if you want the headache you can enable MC across the subnets and have one cache domain. Not worth the headache IMHO, depending on link speed/clients. //A From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Jason Wallace Sent: den 19 december 2014 16:43 To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] PeerDisc QQ Actually folks I think I answered my own question. We are based on SOAP over UDP and that is multicast based. ________________________________ From: [email protected]<mailto:[email protected]> To: [email protected]<mailto:[email protected]> Subject: [mssms] PeerDisc QQ Date: Fri, 19 Dec 2014 15:09:49 +0000 Hi folks OK, dumb query of the day My understanding is that BranchCache Distributed Mode is designed to work on a subnet by subnet basis. So, if we have a remote office with 2 subnets on it, 192,168.10.0 and 192.168.20.0 then we are guaranteed to have 2 cache domains (if that’s what they’re called) If that’s the case then I’d expect PeerDisc to pump out packets 255.255.255.255:3702 but it does not - http://technet.microsoft.com/en-us/library/dd837649(v=WS.10).aspx<http://technet.microsoft.com/en-us/library/dd837649%28v=WS.10%29.aspx> says (and packet traces prove) that the DIP is 239.255.255.0:3702 Why are we using multicast addresses for this then? Jason
