Notes

UDP Checksums

RIP will refuse to run if it determines that UDP checksums are disabled in the kernel. Running without UDP checksums can lead to incorrect routing information being propagated, especially on serial links. This check does not help you determine if RIP packets you receive are missing a checksum, but at least it prevents you from generating these packets and calls attention to the problem.

There are two ways to enable UDP checksums. Your operating system may provide enough source to enable checksums by default. SunOS provides this in /sys/netinet/in_proto.c. Update the source and recompile the kernel.

If your operating system does not provide the relevant source, you can patch the running kernel and disk image with a sequence similar to this (as root):

sun# adb -k -w /vmunix /dev/mem _udp_cksum/W 1 _udp_cksum: 0x0 = 0x1 _udp_cksum?W 1 _udp_cksum: 0x0 = 0x1 ^D sun#

You can probably find the proper name for the UDP checksum value with:

sun# nm -o /vmunix | grep udp_c /vmunix:f80fa35c D _udp_cksum /vmunix:f801bd10 T _udp_ctlinput sun#

IP Multicast support

The OSPF and RIP implementations (and in the future hopefully Router Discovery) make use of IP multicasting facilities. If these facilities are not present, functionality is reduced.

Some systems ship with IP multicasting support, namely BSDI's BSD/386 1.0, Sun's Solaris 2.0 and Silicon Graphics' IRIX. For other systems, IP multicasting support may be available (for example SunOS 4.1.* and some versions of Ultrix), check the FTP directories on ftp://gregorio.stanford.edu/vmtp-ip, gregorio.stanford.edu, ftp://parcftp.xerox.com and ftp://ftp.isi.edu/mbone".

RIP-II and OSPF specify the use of IP multicast on P2P interfaces. Due to bugs in most implementations of the IP multicast code GateD will not be able to specify it's use on these interfaces. GateD will automatically fall back to using the destination address of the P2P link. In the OSPF case, no functionality will be lost, but in the RIP-II case you will loose the ability to pass arbitrary subnet masks via these interfaces.

Another bug in IP multicast support causes multicast packets to local-wire groups to fail if there is not a default route for IP, multicast, or the specific group. As a workaround, GateD installs a route for any local-wire multicast group it uses via the loopback interface. This default is not actually used, but it avoids a kernel bug sending to these groups.

IP Multicast Routing Protocols

Gated now includes support for multicast routing protocols. It implements the router portion of the IGMP protocol to determine local group membership information. It currently supports PIM (Dense Mode) and Distance Vector Multicast Routing Protocol (DVMRP). It tries to be compatible with the 3.3 and 3.5 releases of the IP Multicast distribution from Xerox Parc.

Gated can be configured to use one of three different multicast kernel models. These are distinguished by how multicast forwarding table entries are placed in the kernel.

KRT_IPMULTI_NOCACHE

This model does not provide a protocol independent multicast forwarding cache in the kernel. Therefore, it is not possible to use this type of kernel for IP Multicast Routing with Gated. This includes all releases of the IP Multicast software from Xerox PARC and Stanford University with versions 1.x and 2.x. If your kernel falls in this category, then unfortunately, you cannot use Gated for IP Multicast routing.

KRT_IPMULTI_RTSOCK

Because of the DVMRP dependencies in the 1.x and 2.x releases, a new kernel was designed by some of the Gated developers that would be completely protocol independent. The design assumed that certain features typical of BSD 4.3 reno and later systems (including the routing socket) would be present. When a multicast datagram arrives for a Group,Source pair and no forwarding cache entry exists in the kernel, a request is put on the routing socket to resolve the Group,Source. The routing daemon (who listens on the routing socket) will see the request and generate a forwarding cache entry to be installed in the kernel.

Another goal of the new kernel was to eliminate the use of Virtual Interfaces (or Vifs). Instead, pseudo tunnel interfaces with their own ifnet structures were implemented. This made the software much simpler since a tunnel interface appeared to be just like and other point to point interface in the router.

The implementation also takes advantage of the radix tree that exists in BSD 4.3 Reno systems and later. The Group,Source pairs are installed as a single key in the radix tree as opposed to the more traditional hashing table found in BSD 4.3 systems. A copy of the source patches to this kernel that is applicable to most BSD 4.4 Lite systems is available from ftp://ftp.gated.cornell.edu/pub/multicast

Note: Not yet implemented.

KRT_IPMULTI_TTL0

With this model, the kernel also acts as a protocol independent multicast forwarding cache. Forwarding cache entries are generated on demand as data traffic is forwarded. It uses messages on the IGMP socket to communicate with the routing daemon and request that a forwarding cache entry be calculated. Examples of the use of this model include the Xerox PARC IP Multicast 3.3 and 3.5 kernel releases.

Running GateD on SunOS 4.0 systems

If GateD gets sendto() network unreachable problems when running on SunOS 4.0 systems, add `hostname` to the ifconfig commands for ie0/le0/ec0 in /etc/rc.local. Otherwise SunOS has a misconception of the route to the attached network.

In an attempt to make binaries that read kernel memory compatible between different kernel architectures, Sun has created libkvm.a. Unfortunately, the dynamically loaded versions of these libraries are broken on SunOS 4.* systems, so GateD must be statically linked. This prevents the use of a GateD binary compiled on one kernel architecture (say sun4m) from working on another ( sun4c).

Running GateD on AIX 3.2 systems

AIX 3.2 has networking code based on BSD 4.3 Reno, including variable length subnet masks and the routing socket. Some of the extensions are available when the system is not running in BSD 4.3 compatibility mode (see the compat_43 variable and no). Among these are the ability to determine the destination address of a RIP packet (used when GateD is responding to the ripquery program). GateD can run in either mode with a slight loss of functionality in BSD 4.3 compatibility mode. Make sure you compile with -D_BSD=44!

In order to generate a core dump useful for debugging on AIX 3, the default limit on the core size must be increased. This can be accomplished via the shell, or automatically when GateD is started via gdc. Some compilation-time configuring is necessary for this to work. Either define GDC_CORESIZE=RLIM_INFINITY in the obj/Config file, or define GDC_RESOURCE and use the -c option to gdc at run time.

Compiling GateD on systems with shared libraries

If an assertion failure occurs in task_stdio_read(), it is because a file descriptor was improperly closed. This can occur when the named resolver libraries are improperly installed in the system shared libraries. If the socket used by the shared libraries is not statically initialized to -1, file descriptor zero will be closed when GateD calls endhostent(). The solution is to fix the shared libraries. A workaround would be to not use any symbolic names in the config file and specify options noresolv ;.

Using GateD on AIX 3.1 and 3.2

Problems have been reported with yacc on at least some versions of AIX 3.1 and 3.2. On of the problems is that yacc does not report parse errors to the caller, resulting in GateD trying to run with an incorrect configuration. It is strongly recommended that you obtain GNU bison instead. It is available from ftp://prep.ai.mit.edu/pub/gnu.

Running HELLO and/or EGP on 4.2 based systems

If you would like to run HELLO or EGP on a 4.2 based system such as Ultrix 1.2, 2.0, 2.1 and SunOS 3.x you will need to add the following code to the following modules and rebuild your kernel.

/sys/netinet/in.h: #define IPPROTO_EGP 8 /* exterior gateway protocol */ #define IPPROTO_HELLO 63 /* Fuzzball HELLO protocol */ /sys/netinet/in_proto.c for {\em SunOS 3.x}: { SOCK_RAW, PF_INET, IPPROTO_HELLO, PR_ATOMIC|PR_ADDR, rip_input, rip_output, 0, 0, raw_usrreq, 0, 0, 0, 0, }, { SOCK_RAW, PF_INET, IPPROTO_EGP, PR_ATOMIC|PR_ADDR, rip_input, rip_output, 0, 0, raw_usrreq, 0, 0, 0, 0, }, /sys/netinet/in_proto.c for {\em Ultrix 1.2, 2.0 and 2.2}: { SOCK_RAW, &inetdomain, IPPROTO_HELLO, PR_ATOMIC|PR_ADDR, rip_input, rip_output, 0, 0, raw_usrreq, 0, 0, 0, 0, 0, 0, 0, }, { SOCK_RAW, &inetdomain, IPPROTO_EGP, PR_ATOMIC|PR_ADDR, rip_input, rip_output, 0, 0, raw_usrreq, 0, 0, 0, 0, 0, 0, 0, },