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]> > 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]] > On Behalf Of Jason Wallace > Sent: den 19 december 2014 16:43 > To: [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] > To: [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 says (and > packet traces prove) that the DIP is 239.255.255.0:3702 > > Why are we using multicast addresses for this then? > > Jason > > > >
