MBONE: Multicasting Tomorrow's Internet
phyint [disable] [metric ] [threshold ]
tunnel [metric ] [threshold ]
The phyint command can be used to disable multicast routing on the physical interface identified by local IP address , or to associate a non-default metric or threshold with the specified physical interface. Phyint commands should precede tunnel commands.
The tunnel command can be used to establish a tunnel link between local IP address and remote IP address, and to associate a non-default metric or threshold with that tunnel. The tunnel must be setup in the mrouted.conf files of both ends before it will be used. The keyword "srcrt" can be added just before the keyword "metric" to choose source routing for the tunnel if necessary because the other end has not yet upgraded to use IP encapsulation. Upgrading is highly encouraged. If the methods don't match at the two ends, the tunnel will appear to be up according to mrouted typeouts, but no multicast packets will flow.
The metric is the "cost" associated with sending a datagram on the given interface or tunnel; it may be used to influence the choice of routes. The metric defaults to 1. Metrics should be kept as small as possible, because mrouted cannot route along paths with a sum of metrics greater than 31. When in doubt, the following metrics are recommended:
LAN, or tunnel across a single LAN: 1
any subtree with only one connection point: 1
serial link, or tunnel across a single serial link: 1
multi-hop tunnel: 2 or 3
backup tunnels: sum of metrics on primary path + 1
The threshold is the minimum IP time-to-live required for a multicast datagram to be forwarded to the given interface or tunnel. It is used to control the scope of multicast datagrams. (The TTL of forwarded packets is only compared to the threshold, it is not decremented by the threshold. Every multicast router decrements the TTL by 1.) The default threshold is 1.
Since the multicast routing protocol implemented by mrouted does not yet prune the multicast delivery trees based on group membership (it does something called "truncated broadcast", in which it prunes only the leaf subnets off the broadcast trees), we instead use a kludge known as "TTL thresholds" to prevent multicasts from traveling along unwanted branches. This is NOT the way IP multicast is supposed to work; MOSPF does it right, and mrouted will do it right some day.
Before the November 1992 IETF we established the following thresholds. The "TTL" column specifies the originating IP time-to-live value to be used by each application. The "thresh" column specifies the mrouted threshold required to permit passage of packets from the corresponding application, as well as packets from all applications above it in the table:
TTL thresh
--- ------
IETF chan 1 low-rate GSM audio 255 224
IETF chan 2 low-rate GSM audio 223 192
IETF chan 1 PCM audio 191 160
IETF chan 2 PCM audio 159 128
IETF chan 1 video 127 96
IETF chan 2 video 95 64
local event audio 63 32
local event video 31 1
It is suggested that a threshold of 128 be used initially, and then raise it to 160 or 192 only if the 64 Kb/s voice is excessive (GSM voice is about 18 Kb/s), or lower it to 64 to allow video to be transmitted to the tunnel.
Mrouted will not initiate execution if it has fewer than two enabled vifs, where a vif (virtual interface) is either a physical multicast-capable interface or a tunnel. It will log a warning if all of its vifs are tunnels, based on the reasoning that such an mrouted configuration would be better replaced by more direct tunnels (i.e., eliminate the middle man). However, to create a hierarchical fanout for the MBONE, we will have mrouted configurations that consist only of tunnels.
Once you have edited the mrouted.conf file, you must run mrouted as root. See ipmulticast.README for more information.