All things related to multicast

[David Mitchell <>]

Bill,

one of these hosts is located here at NCAR. I'll follow up with the
sysadmins for that division and see if we can't ensure this traffic
stays local. I'll let the list know if I learn anything interesting.

-David Mitchell


Bill Owens wrote:
> A network engineer at one of our member campuses sent me an
> interesting note this morning, asking for any hints about a problem
> that they were having with spontaneous resets on the management cards
> of some Eaton/Powerware UPSes. Turns out those cards were joining a
> multicast group, 224.0.5.128, and he suspected that something might
> be going on with that.
> 
> I did some poking around, which eventually led to a company called
> Digi International and a protocol of theirs called Advanced Digi
> Discovery Protocol, or ADDP. Indeed it uses 244.0.5.128, and
> udp/2362, which is listed in the ports table as 'digiman'. The
> protocol itself is undocumented and proprietary (though some folks
> have reverse-engineered it) and Wireshark cannot decode it, but
> there's enough info on the Digi website to lead me to believe that it
> could be responsible for unintentional remote resets of equipment
> that listens to that group.
> 
> On the surface, this looks like yet another example of a naive
> developer picking a group address out of the air (eg. Norton Ghost).
> But it's actually more interesting than that; it appears that ADDP is
> the subject of a patent:
> 
> http://www.google.com/patents?vid=USPAT7035257
> 
> Which includes the text,
> 
> "In one embodiment, a predetermined multicast address may be used.
> For example, RFC 1700 identifies addresses ranging from 224.0.5.128
> through 224.0.5.255 and 224.0.6.128 through 224.0.6.255, which may be
> currently unassigned, that are suitable for use."
> 
> 
> The patent was filed in 2002, RFC 1700 is from October 1994, so not
> exactly up-to-date information. And if we consult the IANA multicast
> address assignment list, we see that in October 1998 the range
> 224.0.5.128-224.0.5.191 was assigned to the SIAC Market Service.
> Oops.
> 
> Given that this is a legitimate group, I can't recommend blocking it
> globally. I don't believe that SIAC uses their multicast groups
> externally, but I don't know that for sure.
> 
> There appear to be just four hosts sending to this group at present:
> 
> 128.117.80.161        eol-schroeder.atd.ucar.edu 128.59.160.97
> vtofficecomputer.facil.columbia.edu 130.111.48.188
> LaLonde-Office.umpi.maine.edu 130.39.149.91   no reverse DNS
> 
> If I had to guess, I'd say that those are management PCs running
> Digi's software, since the managed devices seem to stay quiet unless
> they're sent a probe packet. However, the 'sh ip mroute' display on
> one of our backbone routers has a somewhat longer list of speakers,
> some of which may be managed devices, and we have listeners on
> several campuses.
> 
> I'm writing this up for two reasons - one, to let people know that
> they may want to block this group at their edges, if they don't have
> any legitimate traffic on it but do have devices running ADDP. And
> two, so that the next time this address comes across my screen I'll
> be able to find something when I Google for it ;)
> 
> Incidentally, I've sent a support case to Digi to let them know that
> this is at least an issue, and potentially a problem for their
> customers who have multicast-enabled external connectivity. I haven't
> heard anything back yet. . .
> 
> Bill.


-- 
-----------------------------------------------------------------
| David Mitchell 
()
       Network Engineer IV  |
| Tel: (303) 497-1845                      National Center for  |
| FAX: (303) 497-1818                      Atmospheric Research |
-----------------------------------------------------------------