The DVMRP Daemon: mrouted

For your DVMRP routing fun, we chose to cover mrouted (ftp://parcftp.xerox.com/pub/net-research/ipmulti/). Once again, this is not the only tool available for the job, but we’ve chosen to cover it because it is single purpose and freely available, just as with pimd. See the chapter sidebars for other DVMRP options.

The multicasting community has found that DVMRP does not quite suit their needs for internal use. Mainly, the protocol does not perform well when put under heavy load—whereas PIM-SM is quite scalable.Today, this protocol comes into play when connecting your network to the MBONE (http://www.live.com/mbone/), which exclusively uses DVMRP.

While I am not including SNMP coverage, mrouted does support this tool. If you intend to utilize SNMP and mrouted hand-in-hand, see the file mrouted.conf.dist that comes with the package itself.

Multi-Protocol, Multicast Routing with zebra

Another daemon that’s useful in both the unicast and multicast worlds is GNU’s zebra. For unicast, this daemon handles BGP4, OSPF, RIP-1, RIP-2, and more. However, in this case, the multicasting functionality has not been added to the main zebra release quite yet. You can keep up with its progress at http://www.zebra.org/.


Configuring mrouted

Once again, we’re dealing with a single-function daemon. This gives us the benefit of a pretty straightforward configuration process. The configuration file for mrouted is /etc/mrouted.conf. Some of these settings must be presented in a specific order. The chapter will make it clear when this is the case. The rest doesn’t matter; so if you don’t see any directions about ordering, the options are presented in the sequence as they are typically used.

The mrouted configuration file often begins with one or more options of the name statement.You utilize this command in the format

name boundaryname boundaryadd/masklen
						

These three variables are

  • boundaryname. The name that you choose to assign to the particular collection of addresses for which you want to set rules.

  • boundaryadd. The network or subnet address you’re naming.

  • masklen. The number of binary 1s at the beginning of the netmask for the network or subnet that you’re naming.

Typically, the next line involves the cache_lifetime option. It’s used in the format

cache_lifetime seconds
						

seconds sets how long information learned through DVMRP is stored in the kernel. The default is 300, and the guidelines state that you should keep it between 5 minutes (300 seconds) and 1 day (86,400 seconds). After this statement tends to come one of the following two lines:

pruning on 
pruning off 

These two statements control whether or not your DVMRP router supports tree pruning, as you might have guessed.

You can actually end the file right here if you prefer. The mrouted program by default activates all interfaces capable of transmitting multicast data and assigns them default values. Alternatively, you can proceed to set up one or more interfaces. The next command typically used is phyint, which should look familiar if you just read the pimd configuration material. The initial format for phyint in mrouted’s case is

phyint IPaddr
						

IPaddr tells phyint which physical interface you’re referring to and can be an IP address or an interface name, such as eth0. After this, you have a collection of options that you can add to suit your needs:

  • disable. Indicates to route no DVMRP traffic through this interface.

  • metric metric. The cost for sending data from the multicast source to this interface. For an interface to be valid, the metric should be below 31. It’s often recommended to use 1.

  • threshold threshold. The minimum Internet Protocol (IP) time-to-live setting the packet must have before mrouted will bother sending this packet along to the interface. This value is given in seconds.

  • rate_limit rate_limit. The rate in Kbits/second that this interface will accept multicast traffic, if you want to limit this.

  • boundary boundaryname. Apply this set of rules to the network block defined earlier with the name statement. You can have more than one of these options.

  • boundary boundaryadd/masklen. Apply this set of rules to the network block specified by these variables, which are utilized in the same way you would use them in the name statement. You can have more than one of these options.

  • altnet subnet/masklen. If the interface in question leads to a number of subnets, you can refine the data path utilizing this option. subnet refers to the network address for the specific subnet you want to set up, and masklen is the same as it is defined in the name statement. You can have more than one of these options.

  • altnet subnet. If the interface in question leads to a number of subnets, you can refine the data path utilizing this option. subnet refers to the network address for the subnet you want to set up and assumes that there is no netmask needed. You can have more than one of these options.

Now we finally get into an order issue. The final possibility here is the tunnel statement, which you can utilize to set up a unicast method of transporting your multicast data from one mrouted machine to another across unicast-only network space. You must define your tunnels after your physical interfaces. The base format for this item is

tunnel local remote 

As you might guess, local refers to the connected interface on which to start the tunnel—either an IP address or device name—and remote refers to the IP address of the interface to connect to on the other end to receive the data. All of the additional options are identical to those available in phyint: metric, threshold, rate_limit, boundary boundaryname, and boundary boundaryadd/masklen. See the previous bulleted list for definitions of these options and how to set them.

For example, I might set up my configuration file to be as close as possible to the PIM-SM configuration file as follows:

name multi 199.60.103.0/32 
cache_lifetime 21600 

pruning on 
phyint 199.60.103.90 disable 
phyint 199.60.103.91 rate_limit 60 threshold 10  
preference 1029 boundary multi 
phyint 199.60.103.92 rate_limit 60 threshold 10  
preference 1024 boundary multi 
tunnel 199.60.103.92 210.17.105.9 rate_limit 60  
threshold 10 preference 1024 boundary multi 

Running mrouted

After you’ve set up the configuration file, you’re ready to run the DVMRP daemon, mrouted. The usual recommendations apply, such as setting up the daemon to start and stop automatically at boot and shutdown, but not until you’ve run it manually at first to determine what combination of flags and settings works best for your needs. The format for running this daemon is

mrouted flags
						

Yes, that’s it.The available flags are

  • -p. Disable tree pruning.

  • -c file. Utilize the specified configuration file. Be sure to include the path in file.

  • -d. Enter debug level 2. The debugging levels are outlined in Table 6.1.

  • -d level. Enter the specified debug level.

Table 6.1. Debugging Levels Available in mrouted
Level Description
1 Send all syslogd messages to STDERR.
2 Level 1 plus send all messages marked “significant” to STDERR.
3 Level 2 plus send messages recording every packet’s arrival and departure to STDERR.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset