Peter Lister <[EMAIL PROTECTED]> writes: > IP multicast has the advantage that some switches (e.g. Cisco, see > URL) know what it is, so they limit traffic to ports they know (by > snooping the IGMP packets) to be listening. Using a group MAC address > with a frame type that switches don't know mean it is forwarded > everywhere (like a broadcast) unless the switch can talk be told to > set a multicast group with GMRP.
Nice point. This makes a good argument in favor of an ip based solution then. Though I still wonder if the switch can see enough of the data to keep this from happening. I'll have to look into that some more. > There's also the distinct advantage > that IP can be routed. How hard is it to get an official IP multicast > address somewhat like the NTP address? Presumably a (draft) RFC is > needed. With an official address, hardcoding is OK. We need some experience with a proof of concept implementation first. > Although the actual traffic volume probably isn't that great, there > may be an inflationary effect in that if it becomes easy to manage and > store console logs, then there's more motivation to generate info. :) > "Keystroke" traffic in the other direction should be unicast, but if > it is essentially just keystrokes it really *is* minimal. The payload > protocol would need to have a system identifier to connect to the > "right" machine, and preferably crypto authentication, as one normally > wants to keep consoles in a locked room. Encryption doesn't buy anything if the data is predictable. And boot messages are very predictable. Also be very clear there are 2 cases. 1) Having console over ethernet where the normal console assumptions apply (i.e. you have a crossover cable plugged into your ethernet port and plugged into a machine you trust) 2) Using a console over ethernet protocol in a normal network situation. You have to lock it down at least to remove being able to send any characters. And possibly disable it all together. > But... this gets me thinking. Why just reproduce a TTY? For quick debugging. For a trivial model that is generally useful. > Better, surely, > to encapsulate the things we actually want to do in a protocol like DHCP > or SNMP with which one can actually express the concept of e.g. > shutdown. There's still definitely a place for ordinary console output > for the foreseeable future, but it's worth considering whether we could > do something better. Totally agreed. If you are doing anything repeatable over a console protocol you should replace it with DHCP, SNMP or something similiar. But for debugging, especially when all you have is a lan connection a network console protocol looks to be quite useful. > At Sychron, we use our own frame type (not for consoles) and send > quite a lot of multicasts (actually, we need something which doesn't > have a name, a sort of hybrid multicast/anycast). We've had many > debates internally about how much broadcast / multicast traffic we > can put onto a LAN without frightening the horses. > > Cisco on L2 multicasts... > http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/mcst_sol/mcst_ovr.htm Eric
