GateD Configuration Guide - HELLO Configuration

# 6.2.2 Intra-Domain Routing Protocols

## 4. The HELLO Protocol

It's really better not to use HELLO unless you have a specific need for it. We plan to drop it some time around GateD 4.2.

The HELLO protocol is an interior protocol that uses a routing metric based on the length of time it takes a packet to make the trip between the source and the destination. HELLO packets carry timestamp information which allows receivers to compute the shortest delay paths to destinations. The "best" route is the route with the shortest time delay. The unit of time used in HELLO is milliseconds. If a HELLO update packet takes less than 100 milliseconds to travel between two routers, a minimum value of 100 is used for that hop. Thus on networks built of high-speed interfaces HELLO essentially defaults to using hop counts. As in any routing algorithm, HELLO cannot change routes too rapidly or it would be unstable. To avoid instabilities, implementations of HELLO build in hysteresis and "hesitate" to change routes until they have confidence that the change will be lasting.

By default, HELLO, like RIP, uses the kernel interface metric set by the `ifconfig` command to influence the metrics associated with routes as they are installed in the routing table (`metricin`). Since the kernel interface metric is in hops, it must be translated into HELLO's millisecond metric. In order to do that, the following table is used:

    	Hops	HELLO metric
    	   0		   0
    	   1		 100
    	   2		 148
    	   3		 219
    	   4		 325
    	   5		 481
    	   6		 713
    	   7		1057
    	   8	        1567
    	   9	        2322
    	  10	        3440
    	  11	        5097
    	  12	        7552
    	  13	       11190
    	  14	       16579
    	  15	       24564
    	  16	       30000

### HELLO and Network Masks

HELLO derives the network mask of a received network or host from the network mask of the interface from which the packet was received. If a received network or host is on the same natural network as the interface over which it was received, and that network is subnetted (the specified mask is more specific than the natural netmask), the subnet mask is applied to the destination. If bits outside the mask are set, it is assumed to be a host. Otherwise it is assumed to be a subnet.

On point-to-point interfaces, the netmask is applied to the remote address. The netmask on these interfaces is ignored if it matches the natural network of the remote address or is all ones.

Unlike in previous releases, the zero subnet mask (a network that matches the natural network of the interface, but has a more specific, or longer, network mask) is ignored. If this is not desirable, a route filter may be used to reject it.

## The Hello Statement

    hello yes | no | on | off [ {
        broadcast ;
        nobroadcast ;
        preference preference ;
        defaultmetric metric ;
        interface interface_list
                [nohelloin] | [helloin]
                [nohelloout] | [helloout]
                [metricin metric]
                [metricout metric] ;
        trustedgateways gateway_list ;
        sourcegateways gateway_list ;
        traceoptions trace_options ;
    } ] ;

The `hello` statement enables or disables HELLO. If the `hello` statement is not specified, the default is `hello off`. If enabled, HELLO will assume `nobroadcast` when there is only one interface, and `broadcast` when there is more than one interface.

broadcast
  Specifies that HELLO packets will be broadcast regardless of the number of interfaces present. This is useful when propagating static routes or routes learned from anther protocol into HELLO. In some cases, the use of `broadcast` when only one network interface is present can cause data packets to traverse a single network twice.
nobroadcast
  Specifies that HELLO packets will not be broadcast on attached interfaces, even if there are more than one. If a `sourcegateways` clause is present, routes will still be unicast directly to that gateway.
preference preference
  Sets the preference for routes learned from HELLO. The default preference is op. This preference may be overridden by a preference specified in import policy.
defaultmetric metric
  Defines the metric used when advertising routes via HELLO that were learned from other protocols. If not specified, the default value is 30000 (unreachable). This choice of values requires you to explicitly specify a metric in order to export routes from other protocols into HELLO. This metric may be overridden by a metric specified in export policy.
interface interface_list
  Controls various attributes of sending HELLO on specific interfaces. See the section on interface list specification for the description of the interface_list.
  Note that if there are multiple interfaces configured on the same subnet, HELLO updates will only be sent from the first one which the HELLO output is configured. This limitation is required because of the way the Unix kernel operates. It will hopefully be removed in a future release.
  The possible parameters are:
  nohelloin

  Specifies that HELLO packets received via the specified interface will be ignored. The default is to listen to HELLO on all non-loopback interfaces.

  helloin

  This is the default. This argument may be necessary when `nohelloin` is used on a wildcard interface descriptor.

  nohelloout

  Specifies that no HELLO packets will be sent on the specified interfaces. The default is to send HELLO on all broadcast and non-broadcast interfaces when in `broadcast` mode. The sending of HELLO on point-to-point interfaces must be manually configured.

  helloout

  This is the default. This argument is necessary when it is desired to send HELLO on point-to-point interfaces and may be necessary when `nohelloin` is used on a wildcard interface descriptor.

  metricin metric

  Specifies the HELLO metric to add to incoming routes before they are installed in the routing table. The default is the kernel interface metric plus 1 (which is the default HELLO hop count). If this value is specified, it will be used as the absolute value. The kernel metric will not be added. This option is used to make this router prefer HELLO routes learned via the specified interface(s) less than HELLO routes from other interfaces.

  metricout metric

  Specifies the HELLO metric to be added to routes that are sent via the specified interface(s). The default is zero. This option is used to make other routers prefer other sources of HELLO routes over this router.

trustedgateways gateway_list
  Defines the list of gateways from which HELLO will accept updates. The gateway_list is simply a list of host names or IP addresses. By default, all routers on the shared network are trusted to supply routing information. But if the `trustedgateways` clause is specified only updates from the gateways in the list are accepted.
sourcegateways gateway_list
  Defines a list of routers to which HELLO sends packets directly, and not through multicast or broadcast. This can be used to send different routing information to specific gateways. Updates to gateways in this list are not affected by `noripout` on the interface.
traceoptions trace_options
  Specifies the tracing options for HELLO. (See Trace Statements and the HELLO specific tracing options below.)

The default preference is 90. The default metric is 30000.

## Tracing options

The `policy` option logs information whenever a new route is announced, or the metric being announced changes, or a route goes or leaves holddown.

Packet tracing options (which may be modified with `detail`, `send` and/or `recv`):

packets
  All HELLO packets

Last updated April 27, 1997