Sergio As you using layer II VLAN's between your physical switches? If so - make sure your network folks have IGMP turned on - on the switch interlinks.
Cheers Richard On 5 Oct 2011, at 09:38, Sergio Aguilera Cazorla wrote: > Hello, > > Our network administrators say that *our company's switches do not block > multicast or broadcast traffic*. To check if this it's true, we've forgotten > about Reggie and we've written a little Java program that simply uses a > MulticastSocket to send packets to the multicast IP *224.0.1.84 and > attacking the port 4160*. Of course, this program failed in the network > office, while it worked perfectly on my home's network. > > We are completely sure that it's a problem related to multicast packets. > Maybe it's related to Windows XP or 7 Firewall? In the company there is a > Group Policy commanding the Firewall, but we can define some exceptions and > we have the multicast/broadcast response enabled. Is that enough, or is > there some other issue that remains hidden? > > Please, any hint is welcome, because our goal is to deploy this software in > a production environment, not only in a domestic network! > > Thanks and regards > > > > 2011/9/29 Christopher Dolan <[email protected]> > >> Yes, most enterprise switches block multicast by default. That's probably >> your issue. >> >> Another possible issue is reverse DNS. If reggie is broadcasting a private >> hostname or IP address for other machines to call back to it, then it's not >> going to work. We've also had issues with dual-NIC servers where clients >> always try to connect to the primary NIC (as specified in the Windows >> interface binding order) and do not fail over to the secondary NIC. The >> usual cause of that problem is passing a null host to >> TcpServerEndpoint.getInstance() because in that code path, JERI just picks >> the first IP address from a reverse DNS lookup. The solution in that case is >> to instead pass the results of >> InetAddress.getLocalHost().getCanonicalHostName() as the hostname, or >> hard-code the public host name. >> >> I'm suspicious of your "just once" result. Maybe you changed the group >> name? Remember that the group is case-sensitive. >> Chris >> >> >> -----Original Message----- >> From: Sergio Aguilera Cazorla [mailto:[email protected]] >> Sent: Thursday, September 29, 2011 1:16 PM >> To: [email protected] >> Subject: Re: Reggie's visibility in discovery process >> >> Hello, >> >> At last we could perform some testing on Reggie's discovery using multicast >> protocol. I can provide the following results: >> >> - The program performs perfectly when we make a Unicast discovery, >> attacking >> directly the URL where the Lookup service is located. >> >> - We can ping the two machines. Even, we can acces the folder server by the >> HTTP server, and get the reggie-dl.jar classfiles needed to communicate >> with >> the Lookup. >> >> - All machines in the office are Windows XP SP3 and Windows 7. None of the >> combinations server/client XP-7 has thrown a good result. >> >> - We are communicating through switches in the LAN of a enterprise. Do you >> think that multicast packets are bein blocked by intermediate nodes? >> >> - The most misteryous fact: we could perform multicast discovery >> succesfully >> *just once*, the first time we tried. That's suspicious, is there some >> class >> or service that remains hidden and doesn't allow you to perform multicast >> discovery more than once? >> >> Any help on reggie's weird behaviour is very welcome. If I can solve this >> problem, no doubt I will write a short explanation for the community, >> because I think it has to be a very common problem. >> >> Regards. >> >> >> >> 2011/9/22 Иван Бишевац <[email protected]> >> >>> 1. Could you ping two machines? >>> 2. Which operating system you use? >>> 3. Are you communicating through router? >>> >>> >> > > > > -- > *Sergio Aguilera*
