HP -UX Rou tin g Ser vices Ad m in istr a tor ’s
Gu id e
HP -UX 11i v2
Ed ition 1
Ma n u fa ctu r in g Pa r t Nu m ber : B2355-90777
Au gu st 2003
U.S.A.
© Copyright 2003 Hewlett-Packard Development Company L.P. All Rights Reserved.
© Copyright 1989-93 The Open Software Foundation, Inc.
© Copyright 1986 Digital Equipment Corporation.
© Copyright 1990 Motorola, Inc.
© Copyright 1990, 1991, 1992 Cornell University
© Copyright 1989-1991 The University of Maryland
© Copyright 1988 Carnegie Mellon University
Trademark Notices
UNIX is a registered trademark in the United States and other
countries, licensed exclusively through The Open Group.
Intel Itanium Processor Family is a trademark of Intel Corporation in
the U.S. and other countries and is used under license.
3
4
Abou t Th is Docu m en t
1. Over view
The mrouted Routing Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Multicasting Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
DVMRP Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
IP Multicast Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Multicast Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
The gated Routing Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Deciding When to Use gated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
How to Configure mrouted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Configuration Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Starting mrouted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Verifying mrouted Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Displaying mrouted Routing Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Multicast Routing Support Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
The mrinfo Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
The map-mbone Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
The netstat Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3. Con figu r in g ga ted
Configuration Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Configuring gated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Converting the Configuration File from 3.0 to 3.5.9 . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Configuring the RIP Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
RIP Protocol Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Simple RIP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
A: End System on a LAN with RIP Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
B: RIP Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Example of a Large RIP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
A: Cluster Node (or Isolated Node). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
B: Cluster (or Root) Server Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
C: End System on a LAN with RIP Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5
Con ten ts
D: Major Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
E: Major Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Controlling RIP Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Configuring the OSPF Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Planning Your OSPF Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Enabling OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Defining Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
The networks Statement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
The interface Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Stub Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Defining Backbones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
AS External Routes (AS Boundary Routers Only) . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Sample OSPF Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
A: Internal Router (Non-Stub Area). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
B: Area Border Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
C: Internal Router (Stub Area). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Accessing the OSPF MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Configuring RDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
RDP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
RDP Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Customizing Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Specifying a Default Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Installing Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Setting Interface States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Specifying Tracing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Specifying Route Preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Importing and Exporting Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
The import Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
The export Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Examples of import and export Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Starting gated. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Verifying That gated Is Running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Troubleshooting gated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Checking for Syntax Errors in the Configuration File . . . . . . . . . . . . . . . . . . . . . . . 101
6
Tracing gated Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Operational User Interface for gated – gdc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
The gated Routing Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
The ripquery Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
The ospf_monitor Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Common Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Problem 1: gated does not act as expected. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Problem 2: gated deletes routes from the routing table.. . . . . . . . . . . . . . . . . . . . 106
Problem 3: gated adds routes that appear to be incorrect. . . . . . . . . . . . . . . . . . . 107
Problem 4: gated does not add routes that you think it must. . . . . . . . . . . . . . . . 108
In d ex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
7
Con ten ts
8
Abou t Th is Docu m en t
This manual describes the various routing daemons supported in the
HP-UX 11i v2 operating system.It is one of the five new manuals
documenting the Internet Services suite of products. See “Related
Documentation” on page 11 for a list of the other new Internet Services
manuals. These manuals replace the manual Installing and
Administering Internet Services (B2355-90685), which was shipped with
previous releases of the operating system.
This manual assumes that the HP-UX 11i v2 operating system software
and the appropriate files, scripts, and subsets are installed.
In ten d ed Au d ien ce
This manual is intended for system and network administrators
responsible for managing the Routing Services. Administrators are
expected to have knowledge of operating system concepts, commands,
and the various routing protocols. It is also helpful to have knowledge of
Transmission Control Protocol/Internet Protocol (TCP/IP) networking
concepts and network configuration; this manual is not a TCP/IP or a
routing tutorial.
HP -UX Relea se Na m e a n d Relea se Id en tifier
Each HP-UX 11i release has an associated release name and release
identifier. The uname(1) command with the -roption returns the
release identifier. Table 1 shows the releases available for HP-UX 11i.
Ta ble 1
HP -UX 11i Relea ses
Relea se
Id en tifier
Su p p or ted P r ocessor
Ar ch itectu r e
Relea se Na m e
B.11.11
B.11.20
B.11.22
B.11.23
HP-UX 11i v1
PA-RISC
HP-UX 11i v1.5 Intel Itanium Processor Family
HP-UX 11i v1.6 Intel Itanium Processor Family
HP-UX 11i v2.0 Intel Itanium Processor Family
9
P u blish in g Histor y
Table 2 provides, for a particular document, the manufacturing part
number, the respective operating systems, and the publication date.
Ta ble 2
P u blish in g Histor y Deta ils
Docu m en t
Ma n u fa ctu r in g
Pa r t Nu m ber
Op er a tin g
System
Su p p or ted
P u blica tion
Da te
B2355-90110
B2355-90147
B2355-90685
10.x
11.0
June 1996
October 1997
11.11
11.20
11.22
December 2000
B5969-4360
11.22
April 2002
Wh a t Is in Th is Docu m en t
HP-UX Routing Services Administrator’s Guide is divided into chapters,
each of which contain information about configuring the routing services.
Table 3 describes the content in more detail.
Ta ble 3
Docu m en t Or ga n iza tion
Ch a p ter
Overview
Presents an overview of the Routing
they support.
Configuring mrouted
Configuring gated
Describes how to configure mroutedand
various configuration commands in
mrouted.
Describes how to configure gatedon RIP,
OSPF, and RDP protocols. This chapter
also describes how to specify tracing
options, route preference, and some
troubleshooting measures in gated.
10
Rela ted Docu m en ta tion
For more information about the Internet Services suite of products, see
the following books:
•
HP-UX Internet Services Administrator’s Guide
Provides an overview of the Internet Services products and describes
how to install and configure them on your HP-UX 11i v2 operating
system. You can access this manual at the following URL:
0Services
•
HP-UX Mailing Services Administrator’s Guide
Provides information about the Mail User Agents (elm, mailx, mail)
and Mail Transport Agent (Sendmail) used in the HP-UX 11i v2
operating system. This manual also contains a description of
configuring and administering Sendmail on your system. You can
access this manual at the following URL:
•
HP-UX IP Address and Client Management Administrator’s Guide
Provides an overview of the IP address and client management
implementations on the HP-UX 11i v2 operating system, where
BIND, DHCPv6, and SLP deal with client management, and NTP
deals with IP address management. You can access this manual at
the following URL:
0Services
•
•
HP-UX Remote Access Services Administrator’s Guide
Provides information about the Remote Access Services available in
the HP-UX 11i v2 operating system: r-commands, WU-FTP, and
telnet. You can access this manual at the following URL:
Request for Comments (RFC)
11
Many sections of this manual refer to RFCs for more information
about certain networking topics. These documents publicize Internet
standards, new research concepts, and status memos about the
Internet. You can access the full range of RFC documents and more
information about the Internet Engineering Task Force (IETF) at the
following URL:
You can obtain additional information about mroutedand IP
multicast routing from the following RFC (Request for Comment)
documents:
— RFC 1075: Distance-Vector Multicast Routing Protocol
— RFC 1112: Host Extensions for IP Multicasting
Other Documents
•
HP does not maintain and own the following information. As such,
their content and availability are subject to change without notice.
The MBONE FAQ
The Multicast Backbone (MBONE) is a virtual network implemented
on top of the physical Internet. It supports routing of IP multicast
packets. It originated as a cooperative, volunteer effort to support
experimentation in audio and video teleconferencing over the
Internet. You can find an HTML-formatted version of the MBONE
FAQ at the URL:
iknow Topics of Interest
•
HP iknow Topics of Interest describe some networking concepts and
tasks, as well as other topics. You can find these documents on the
HP-UX networking communications home page at the following URL
Typ ogr a p h ica l Con ven tion s
This document uses the following typographic conventions:
audit(5)
An HP-UX manpage. In this example, audit is the
name and 5 is the section in the HP-UX Reference. On
the Web and on the Instant Information CD, it may be
12
a hot link to the manpage itself. From the HP-UX
command line, you can enter “man audit” or “man 5
audit” to view the manpage. See man(1).
Book Title
The title of a book. On the Web and on the Instant
Information CD, it may be a hot link to the book itself.
ComputerOut
Command
Text displayed by the computer.
A command name, qualified command phrase, daemon,
file, or option name.
$
The system prompt for the Bourne, Korn, and POSIX
shells.
#
The superuser prompt.
Variable
The name of a variable that you may replace in a
command or function or information in a display that
represents several possible values.
[ ] { }
In syntax definitions, square brackets indicate items
that are optional and braces indicate items that are
required.
(Ctrl+A)
Bold
This symbol indicates that you hold down the first
named key while pressing the key or mouse button that
follows the plus.
The defined use of an important word or phrase.
HP En cou r a ges You r Feed ba ck
HP welcomes any comments and suggestions you have on this manual.
You can send your comments in the following ways:
•
•
Using a feedback form located at the following URL:
Please include the following information along with your comments:
•
The full title of the manual and the part number. (The part number
appears on the title page of printed and PDF versions of a manual.)
•
The section numbers and page numbers of the information on which
you are commenting.
13
•
The version of HP-UX that you are using.
14
1
Over view
A r ou ter is a device that has multiple network interfaces and that
transfers Internet Protocol (IP) packets from one network or subnet to
another within an internetwork. In many IP-related documents, this
device is also referred to as a gateway. The term router is used in this
Chapter 1
15
Overview
manual. The router stores all the routing information in the form of a
routing table. Routing tables contain the routes to reach a particular
network, and also identify the router to which the datagram packet can
be passed for this purpose. The routing tables must contain the latest
routing information. Routing protocols perform the task of updating the
routing tables with the latest routing information.
The primary function of a routing protocol is to exchange routing
information with other routers. Routing daemons perform the task of
exchanging routing information with other routers. The routing daemons
supported on the HP-UX 11i v2 operating system are mroutedand gated
3.5.9.
troubleshooting information is provided in this manual.
This chapter contains information about the following topics:
•
•
“The mrouted Routing Daemon” on page 17
“The gated Routing Daemon” on page 22
16
Chapter 1
Overview
The mrouted Routing Daemon
Th e m r ou ted Rou tin g Da em on
mrouted(pronounced “M route D”) is a routing daemon that forwards IP
multicast datagrams, within an autonomous network, through routers
that support IP multicast addressing. mroutedimplements the
Distance-Vector Multicast Routing Protocol (DVMRP). The ultimate
destination of multicast datagrams are host systems that are members of
one or more multicast groups.
Multicasting enables a client to establish one-to-many and
many-to-many communication with other hosts and is used extensively
in networking applications such as audio and video teleconferencing,
where multiple hosts need to communicate with each other
simultaneously.
NOTE
You cannot use System Administration Manager (SAM) to configure
mrouted.
mroutedroutes multicast datagram packets only on certain network
interfaces, such as EISA Ethernet (lan2) and EISA FDDI (from a
provider other than HP), and the interface types vary depending on the
system platform.
When you install the HP-UX 11i v2 operating system, mroutedis
automatically installed on your system.
For more information on mrouted, type man 1m mroutedat the HP-UX
prompt.
Mu ltica stin g Over view
This section describes the multicast routing protocol implemented in
mrouted, and the multicast addresses and groups.
DVMRP P r otocol
mroutedimplements the Distance-Vector Multicast Routing Protocol
(DVMRP). You can use DVMRP, an Interior Gateway Protocol (IGP), to
route multicast datagrams within an autonomous network. The primary
purpose of DVMRP is to maintain the shortest return paths to the source
Chapter 1
17
Overview
The mrouted Routing Daemon
of the multicast datagrams. You can achieve this by using topological
knowledge of the network to implement a multicast forwarding
algorithm called Truncated Reverse Path Broadcasting (TRPB).
mroutedstructures routing information in the form of a p r u n ed
broadcast delivery tree that contains routing information. mrouted
structures routing information only to those subnets that have members
of the destination multicast group. In other words, each router
determines which of its virtual network interfaces are in the shortest
path tree. In this way, DVMRP can determine if an IP multicast
datagram needs to be forwarded. Without such a feature, the network
bandwidth can easily be saturated with the forwarding of unnecessary
datagrams.
Because DVMRP routes only multicast datagrams, you must handle
routing of unicast or broadcast datagrams using a separate routing
process.
To support multicasting across subnets that do not support IP
multicasting, DVMRP provides a mechanism called tu n n ellin g.
Tunnelling forms a virtual point-to-point link between pairs of mrouted
routers by encapsulating the multicast IP datagram within a standard
IP unicast datagram using the IP-in-IP protocol (IP protocol number 4).
This unicast datagram, containing the multicast datagram, is then
routed through the intervening routers and subnets. When the unicast
datagram reaches the tunnel destination, which is another mrouted
router, the unicast datagram is stripped away and the mrouteddaemon
forwards the multicast datagram to its destinations.
Figure 1-1 shows a tunnel formed between a pair of mroutedrouters.
Figu r e 1-1
Tu n n el Ma d e w ith m r ou ted Rou ter s
Nonmulticast
Multicast
Transmitter
Multicast
Recipient
DVMRP Tunnel
Endpoint
DVMRP Tunnel
Endpoint
Router
R2
Node
N
Router
R1
Node
M
Tunnel
18
Chapter 1
Overview
The mrouted Routing Daemon
In this figure, the mroutedrouter R1 receives a multicast packet from
node M. Because R1 is configured as one end of a tunnel, R1
encapsulates the IP multicast packet in a standard unicast IP packet
addressed to the mroutedrouter R2. The packet, now treated as a
normal IP packet, is sent through the intervening nonmulticast network
to R2. R2 receives the packet and removes the outer IP header, thereby
restoring the original multicast packet. R2 then forwards the multicast
packet through its network interface to node N.
IP Mu ltica st Ad d r esses
An IP Internet address can be either a 32-bit or a 128-bit address. Each
host on the Internet is assigned a unique IP address. There are four
classes of IP addresses: Class A, Class B, Class C, and Class D. Class D
IP addresses are identified as IP multicast addresses. Class A, Class B,
and Class C IP addresses are composed of two parts: a network ID
(n etid ) and a host ID (h ostid ). Class D IP addresses are structured
differently, as shown in Figure 1-2.
Figu r e 1-2
Cla ss D IP Mu ltica st Ad d r ess For m a t
31
0 1 2 3 4
1 1 1 0
Multicast Group Address
The first 4 bits (0 through 3) identify the address as a multicast address.
Bits 4 through 31 identify the m u ltica st gr ou p . Multicast addresses are
in the range 224.0.0.0 through 239.255.255.255. Addresses 224.0.0.0
through 224.0.0.255 are reserved, and address 224.0.0.1 is permanently
assigned to the a ll h osts gr ou p . The all hosts group is used to reach all
the hosts on a local network that participate in IP multicasting. The
addresses of other permanent multicast groups are published in RFC
1060 (Assigned Numbers, March 1990).
You can use IP multicast addresses only as destination addresses, and
they must never appear in the source address field of a datagram.
Internet Control Message Protocol (ICMP) error messages are not
generated for multicast datagrams.
Because IP Internet addressing is a software manifestation of the
underlying physical network, you must map IP addresses to physical
addresses that the hardware comprising the network understands.
Chapter 1
19
Overview
The mrouted Routing Daemon
Normally, IP multicast addresses are mapped to 802.3 or Ethernet
multicast addresses. The IP multicasting addressing scheme, similar to
Ethernet’s scheme, uses the datagram’s destination address to indicate
multicast delivery.
When an IP multicast address is mapped to an Ethernet multicast
address, the low-order 23 bits of the IP multicast address are placed into
the low-order 23 bits of the special Ethernet multicast address. The
hexadecimal value of the special Ethernet multicast address is
01-00-5E-00-00-00. The resultant Ethernet address, however, is not
unique, because only 23 out of the 28 bits representing the multicast
address are used.
Mu ltica st Gr ou p s
A m u ltica st gr ou p comprises hosts with an intention to join the
multicast group by listening to the same IP multicast address. Group
membership is dynamic, that is, a host may join or leave a group at any
time. A host may be a member of one or more groups simultaneously.
Additionally, a host is allowed to send multicast datagrams to a group
without being a member of the group.
You can assign multicast addresses to transient groups because the
multicast address are often temporary. A typical transient group
scenario is when users run an application that dynamically registers to
specific multicast addresses, which are discarded later when all members
of the group have left. Some multicast addresses may be assigned to
permanent groups that always exist, even when their membership is
empty.
Both hosts and mroutedrouters that participate in IP multicasting use
the Internet Group Management Protocol (IGMP) to communicate
multicast group information among themselves. Hosts use IGMP to
inform mroutedrouters that they are joining a group. mroutedrouters
use IGMP to pass multicast routing information to other mrouted
routers, and to check whether a host is still an active group member.
The underlying TCP/IP stack must support ICMP to participate in IP
multicasting. While IGMP defines a standard for communicating
information, it does not define a standard for how the multicast
information is propagated among multicast routers. Consequently,
DVMRP enables multicast routers to efficiently communicate group
membership information among themselves. DVMRP uses IGMP
messages to carry routing and group membership information. DVMRP
20
Chapter 1
Overview
The mrouted Routing Daemon
also defines IGMP message types that enable hosts to join and leave
multicast groups, and that allow multicast routers to query one another
for routing information.
Chapter 1
21
Overview
The gated Routing Daemon
Th e ga ted Rou tin g Da em on
gated(pronounced “gate D”) is a routing daemon that updates routing
tables in internetwork routers. Developed at Cornell University, gated
handles the Routing Information Protocol (RIP), External Gateway
Protocol (EGP), Border Gateway Protocol (BGP), Open Shortest Path
First (OSPF) routing protocol, and the Router Discovery Protocol (RDP),
or any combination of these protocols.
Routing protocols are designed to find a path between network nodes. If
multiple paths exist for a given protocol, the shorter paths are usually
chosen. Each protocol has a cost or a metric that it applies to each path.
In most cases, the lower the cost or metric for a given path, the more
likely a protocol will choose it.
NOTE
You cannot use System Administration Manager (SAM) to configure
gated.
Upon startup, gatedreads the kernel routing table on the local machine.
gatedmaintains a complete routing table in the user space, and keeps
the kernel routing table (in the kernel space) synchronized with this
table.
In large local networks, multiple paths often exist to other parts of the
local network. You can use gatedto maintain nearly optimal routing to
other parts of the local network, and to recover from link failures.
Ad va n ta ges
gatedoffers the following advantages:
•
Dynamic routing eliminates the need to reset routes manually. When
network failures occur, routes are automatically rerouted.
•
•
Dynamic routing facilitates adding and administering nodes.
Dynamic routing lowers the cost of operating complex Internet
systems.
22
Chapter 1
Overview
The gated Routing Daemon
• gatedtranslates among several protocols, passing information
within or between IP routing domains or autonomous systems.
Au ton om ou s system (AS) is used here to refer to a group of
connected nodes and routers in the same administrative domain that
exchange routing information via a common routing protocol.
• gatedprovides the system administrator flexibility in setting up and
controlling network routing. For example, gatedcan listen to
network traffic at specified routers, determine available routes, and
update local routing tables accordingly.
Decid in g Wh en to Use ga ted
gatedis mostly used in large networks, or in small networks connected
to larger wide area networks.
You must run gatedon routers (gateways) to send the routing
information to other routers. gatedsupports many routing protocols that
allow routers to build and maintain dynamic routing tables. However,
gatedalso supports RIP, which runs on end systems (systems with only
one network interface) as well as on routers.
NOTE
gatedalso supports RDP as a client. RDP will replace rdpd.
gatedis useful in topologies with multiple routers and multiple paths
between parts of the network. gatedallows routers to exchange routing
information and to change routing information dynamically to reflect
topology changes and maintain optimal routing paths.
Alternatively, you can configure IP routes manually with the route (1M)
command. For end systems in subnets with only one router (gateway) to
the Internet, manually configuring a default route is usually more
efficient than running gated. For more details on manually
manipulating the routing tables, type man 1M routeat the HP-UX
prompt.
When connected to wide area networks, you can use gatedto inject local
routing information into the wide area network’s routing table.
Chapter 1
23
Overview
The gated Routing Daemon
Rou tin g P r otocols
For routing purposes, networks and gateways are logically grouped into
autonomous system (AS). Companies and organizations that want to
connect to the Internet and form an AS must obtain a unique AS number
from the Internet Assigned Numbers Authority (IANA).
An interior gateway protocol distributes routing information within the
autonomous system. An exterior gateway protocol distributes general
routing information about an autonomous system to other autonomous
systems.
Dividing networks into autonomous systems keeps route changes inside
the autonomous system from affecting other autonomous systems. When
routes change within an autonomous system, the new information need
not be propagated outside the autonomous system if it is irrelevant to
gateways outside the autonomous system.
gatedsupports the following interior gateway protocols, as defined in
IETF RFCs:
•
Routing Information Protocol (RIP) is a common routing protocol
used within an autonomous system. A de facto industry standard, it
is also used by routed, a service distributed by Berkeley. RIP is not
intended for use in wide area network (WAN) applications. There are
currently two versions of RIP implementations: Version 1, as defined
in RFC 1058, and Version 2, as defined in RFC 1388. gatedsupports
all Version 1 features and most of the features of Version 2. The
following Version 2 features are not supported: RIP management
information base (MIB) route tag, and route aggregation. gated 3.5.9
supports authentication.
•
Open Shortest Path First (OSPF), similar to RIP, is a routing
protocol that allows routing information to be distributed between
routers in an autonomous system. Each router on the network
transmits a packet that describes its local links to all other routers.
The distributed database is then built from the collected
descriptions. If a link fails, updated information floods the network,
allowing all routers to recalculate their routing tables at the same
time. OSPF is more suitable than RIP for routing in complex
networks with many routers. gated3.0 supports most of the features
of OSPF Version 2, as described in RFC 1247, except the IP type of
service (TOS) routing feature. Equal cost multipath routes are
limited to one hop per destination, because the HP-UX kernel
supports only one gateway per route.
24
Chapter 1
Overview
The gated Routing Daemon
•
HELLO is designed to work with routers called Fuzzballs. Most
installations use RIP or OSPF instead of HELLO. The HELLO
protocol is no longer supported on HP-UX. You can use RIP or OSPF
instead, because they are internal routing protocols.
NOTE
Do not mix RIP and OSPF protocols within a single network, because the
routing information may conflict.
Table 1-1 compares the advantages and disadvantages of the RIP and
OSPF protocols.
Ta ble 1-1
Com p a r ison of RIP a n d OSP F P r otocols
RIP
OSP F
Advantage: RIP is easy to
configure.
Disadvantage: OSPF is
complicated to configure and
requires network design and
planning.
Advantage: An end system (a
system with only one network
interface) can run RIP in passive
mode to listen for routing
information.
Disadvantage: OSPF does not
have a passive mode.
Disadvantage: RIP may be slow
Advantage: OSPF is quick to
to adjust for link failures.
adjust for link failures.
Chapter 1
25
Overview
The gated Routing Daemon
Ta ble 1-1
Com p a r ison of RIP a n d OSP F P r otocols (Con tin u ed )
RIP
OSP F
Disadvantage: RIP generates
more protocol traffic than OSPF,
because it propagates routing
information by periodically
transmitting the entire routing
table to neighbor routers.
Advantage: OSPF generates less
protocol traffic than RIP,
because (i) Each router
transmits information only
about its links instead of the
whole routing table, and (ii)
OSPF allows you to divide an
autonomous system into areas,
each with a designated router
that exchanges inter-area
routing information with other
routers. Intra-area routing
information is isolated to a
single area.
Disadvantage: RIP is not
appropriate for large networks,
because RIP packet size
increases as the number of
networks increases.
Advantage: OSPF works well in
large networks.
gatedsupports the following exterior gateway protocols:
•
The External Gateway Protocol (EGP) permits a node on the
NSFNET ba ck bon e to exchange information with other backbone
nodes about reaching a destination. You can use EGP to
communicate routing information between autonomous systems. The
EGP protocol will be obsoleted in a future release of HP-UX. Use
BGP instead of the EGP protocol. BGP offers more flexibility and
requires less bandwidth than EGP.
•
The Border Gateway Protocol (BGP) is intended as a replacement for
EGP. BGP uses path attributes to select routes. One of the attributes
that BGP can pass is the sequence of autonomous systems that must
be traversed to reach a destination. gatedsupports BGP Versions 2,
3, and 4, as described in RFCs 1163 and 1267.
gatedalso supports the Router Discovery Protocol (RDP), which is
neither an interior nor an exterior gateway protocol. RDP is used to
inform hosts of the existence of routers to which the hosts can send
26
Chapter 1
Overview
The gated Routing Daemon
packets. It is used instead of, or in addition to, a statically configured
default router. Router discovery consists of two parts: a server part that
runs on routers, and a client part that runs on hosts.
Chapter 1
27
Overview
The gated Routing Daemon
28
Chapter 1
2
Con figu r in g m r ou ted
This chapter describes how to configure mroutedand the various
configuration commands in mrouted. It also provides information on
starting and verifying the mroutedinstallation. A description of the
mroutedrouting tables is also provided, along with the various multicast
Chapter 2
29
Configuring mrouted
•
•
•
•
•
“Starting mrouted” on page 36
“Verifying mrouted Operation” on page 37
“Displaying mrouted Routing Tables” on page 38
“Multicast Routing Support Tools” on page 41
30
Chapter 2
Configuring mrouted
How to Configure mrouted
How to Con figu r e m r ou ted
When the mrouteddaemon starts, it automatically reads the default
configuration file /etc/mrouted.conf. You can override the default
configuration file by specifying an alternate file while invoking mrouted.
See “Starting mrouted” on page 36 for more information. If you change
the /etc/mrouted.conffile while mroutedis running, issue the
following command to reread the configuration file:
kill -HUP
By default, mroutedautomatically configures itself to forward on all
multicast-capable interfaces, excluding the loopback interface that has
the IFF_MULTICASTflag set. Therefore, you do not need to explicitly
configure mrouted, unless you need to configure tunnel links, change the
default operating parameters, or disable multicast routing over a specific
physical interface.
Con figu r a tion Com m a n d s
You can define the configuration commands in the /etc/mrouted.conf
configuration file. mroutedsupports five configuration commands:
phyint, tunnel, cache_lifetime, pruning, and name. One or more
options are associated with each command.
The syntax of each command is as follows:
phyint local-addr [disable] [metric m] [threshold t] [rate_lim
it b]
[boundary (boundary-name|scoped-addr/mask-len)]
[altnet network/mask-len]
tunnel local-addr remote-addr [metric m] [threshold t] [rate_l
imit b]
[boundary (boundary-name|scoped-addr/mask-len)]
cache_lifetime ct
pruning off/on
name boundary-name scoped-addr/mask-len
phyint
Chapter 2
31
Configuring mrouted
How to Configure mrouted
You can use the phyintcommand to disable multicast routing on the
physical interface identified by the local IP address, local-addr(see
Figure 2-1), or to associate a nondefault metricor thresholdwith the
specified physical interface. Alternatively, you can replace the local IP
address, local-addr, with the interface name, such as lan0. If phyintis
additional subnet (one altnetoption for each subnet).
tunnel
You can use the tunnelcommand to establish a tunnel link between the
local IP address, local-addr, and the remote IP address, remote-addr
(see Figure 2-1). You can also use this command to associate a nondefault
metricor thresholdvalue with the tunnel. You can replace the local IP
address, local-addr, with the interface name, such as lan0. Similarly,
you can replace the remote IP address, remote-addr, by a host name,
but only if the host name has a single IP address associated with it.
Before you can use a tunnel, it must be set up in the mrouted
configuration files of both the mroutedrouters participating in the
tunnel. mrouted3.8 does not support the srcrtoption. (It provided
backward compatibility with older versions of mroutedthat implemented
IP multicast datagram encapsulation using IP source routing.)
32
Chapter 2
Configuring mrouted
How to Configure mrouted
NOTE
A phyintcommand must precede a tunnelcommand. All the phyint
and tunnelcommand options must be placed on a single line except for
the boundaryand altnetoptions, which can begin on a separate line.
Figu r e 2-1
Mu ltica st Netw or k Exa m p le Con figu r a tion
mrouted
Router
mrouted
Router
Node
Node
195.5.5.5
mrouted
193.3.3.3
mrouted
Router
195.5.6.7
Node
Router
Node
193.3.4.5
Nonmulticast
phyint 193.3.3.3
Tunnel 193.3.4.5 195.5.5.5
Boundary 193.3.3.3/16
phyint 195.5.6.7
Tunnel 195.5.5.5 193.3.4.5
The metricis the cost, or overhead, associated with sending a datagram
on the given interface or tunnel, and is used primarily to influence the
choice of routes over which the datagram is forwarded; the larger the
value, the higher the cost. You must keep metrics as small as possible,
because mroutedcannot route along paths with metrics greater than 31.
In general, use a metricvalue of 1 for all links unless you are
specifically attempting to force traffic to take another route. In this case,
the metric of the alternate path should be the sum of the metrics on the
primary path + 1. The default metricvalue is 1.
The thresholdis the minimum IP time-to-live (TTL) required for a
multicast datagram to be forwarded to a given interface or tunnel. It
controls the scope of multicast datagrams. If the TTL value in the
datagram is less than the thresholdvalue, the datagram is dropped; if
the TTL is greater than or equal to the thresholdvalue, the packet is
forwarded. The default thresholdvalue is 1.
Chapter 2
33
Configuring mrouted
How to Configure mrouted
The TTL value of forwarded packets is only compared with the
thresholdvalue; it is not decremented by the threshold. An
application that initiates the IP multicast datagram sets the TTL, and
typically represents the number of subnets, or hops, the datagram has to
traverse to reach its destination. Every time a multicast datagram
passes through a multicast router, the TTL value is decremented by 1.
HP recommends that you use the default thresholdvalue unless you
have a specific reason to set it otherwise.
In general, all interfaces connected to a particular subnet or tunnel
should use the same metricand thresholdvalues for that subnet or
tunnel.
You can use the rate_limitoption to specify a certain bandwidth in
Kbits/second which is allocated to multicast traffic. The default value is
500Kbps on tunnels and 0 (unlimited) on physical interfaces.
You can use the boundaryoption to configure an interface as an
administrative boundary for the specified boundary-nameor
scoped-addr(scoped address). You can specify more than one boundary
option in the phyintand tunnelcommands. Packets belonging to the
scoped address, which is an IP multicast group address, are not
forwarded on this interface. mask-lenindicates the number of leading
1s in the mask applied (by means of a bitwise logically AND operation) to
the scoped address. For example, the statement boundary
239.2.3.3/16would result in the mask 255.255.0.0 being calculated by
means of an AND operation with 239.2.3.3 to isolate the first two octets,
239.2, of the scoped address. Therefore, all IP multicast addresses
beginning with 239.2 will not be forwarded on the specified interface.
The primary use of the boundaryoption is to allow concurrent use of the
same IP multicast addresses on downstream subnets, without
interfering with multicast broadcasts using the same IP multicast
addresses on subnets that are upstream from the mroutedgateway.
The cache_lifetimevalue determines the amount of time that a cached
multicast route remains in the kernel before timing out. This value is
specified in seconds and must be between 300 (5 minutes) and 86400 (24
hours). The default value is 300.
You can use the pruning offcommand to explicitly configure mrouted
as a nonpruning router. When pruning is off, IP multicast datagrams
are forwarded to leaf subnets of the broadcast routing tree even when
34
Chapter 2
Configuring mrouted
How to Configure mrouted
those leaf subnets do not contain members of the multicast destination
group. Use only nonpruning mode for testing. The default mode for
pruning is on.
You can use the namecommand to assign a name (boundary-name) to a
boundary (a scoped-addr/mask-lenpair) to simplify the configuration
task.
mroutedterminates if it has less than two enabled virtual interfaces
(VIFs), where a VIF is either a physical multicast-capable interface or a
tunnel. It logs a warning message if all the VIFs are tunnels. HP
recommends that you replace such configuration settings with more
direct tunnels.
Chapter 2
35
Configuring mrouted
Starting mrouted
Sta r tin g m r ou ted
You can start mroutedfrom the HP-UX prompt or from within a shell
script by issuing the following command:
/etc/mrouted [-p] [-c config_file] [-d debug_level]
The -poption disables pruning by overriding the pruning onstatement
within the /etc/mrouted.confconfiguration file. You must use this
option for testing purposes only.
The -c option overrides the default configuration file
/etc/mrouted.conf. Use config_fileto specify an alternate
configuration file.
The -d debug_leveloption specifies the debug level. debug_levelcan
be in the range 0 to 3. To know more about debug_levelvalues, type man
1M mroutedat the HP-UX prompt.
By default, mroutedalways writes warning and error messages to the
system log daemon. You can retrieve these messages from the system log
file, syslog.log, located in the /var/adm/syslogdirectory.
For convenience in sending signals, mroutedwrites its pidto the
/var/tmp/mrouted.pidfile upon startup.
36
Chapter 2
Configuring mrouted
Verifying mrouted Operation
Ver ifyin g m r ou ted Op er a tion
You can use one or more of the following methods to verify mrouted
operation:
•
•
•
Retrieve the vir tu a l in ter fa ce ta ble and the m u ltica st r ou tin g
See “Displaying mrouted Routing Tables” on page 38 for information
on retrieving these tables.
Retrieve the r ou tin g ca ch e ta ble to verify if the routing and cache
information is appropriate for your configuration of mrouted. See
“Displaying mrouted Routing Tables” on page 38 for information on
retrieving this table.
Examine the syslog file /var/adm/syslog/syslog.logfor warning
and error messages that indicate the status of mrouted. Upon
startup, mroutedlogs a startup message in the syslog file that
indicates the mroutedversion number, such as mrouted version
3.8.
•
Issue the following ps(process status) command to search for the
string “mrouted”, using grep, to determine if the mroutedprogram is
running:
ps -ef | grep mrouted
Chapter 2
37
Configuring mrouted
Displaying mrouted Routing Tables
Disp la yin g m r ou ted Rou tin g Ta bles
mroutedcontains three routing tables: the virtual interface table, the
multicast routing table, and the multicast routing cache table.
The virtual interface table displays the following topological information
for each virtual interface:
•
•
•
Physical and tunnel interfaces.
The number of incoming and outgoing packets at each interface.
The value of specific configuration parameters, such as metricand
threshold.
An example virtual interface table is as follows:
Vif Local
Address
Metric Thresh Flags
0
36.2.0.8 subnet:
groups:
36.2
1
1
querier
224.0.2.1
224.0.0.4
3456
pkts in:
pkts out:
2322323
1
36.11.0.1 subnet:
groups:
36.11
1
1
querier
224.0.2.1
224.0.1.0
224.0.0.4
345
pkts in:
pkts out:
3456
2
36.2.0.8 tunnel:
36.8.0.77 3
1
38
Chapter 2
Configuring mrouted
Displaying mrouted Routing Tables
peers:
36.8.0.77 (2.2)
boundaries: 239.0.1
239.1.2
pkts in:
34545433
The multicast routing table displays connectivity information for each
subnet from which a multicast datagram can originate.
The multicast routing cache table is a duplicate copy of the kernel
forwarding cache table. It contains the status information for multicast
destination group-origin subnet pairs.
mroutedretrieves these tables by sending an appropriate signal to the
mrouteddaemon. mroutedresponds to the following signals:
HUP
INT
Restarts mrouted. The configuration file is reread each
time this signal is evoked.
Terminates mroutedby sending messages to all
neighboring routers.
TERM
USR1
The same as INT.
Defined as signal 16, dumps the internal routing tables
(virtual interface table and multicast routing table) to
/usr/tmp/mrouted.dump.
USR2
QUIT
Defined as signal 17, dumps the multicast routing
cache tables to /usr/tmp/mrouted.cache.
Dumps the internal routing tables (virtual interface
table and multicast routing table) to stderr(only if
mroutedwas invoked with a nonzero debug level).
You can send signals to mroutedby issuing the HP-UX killcommand at
the HP-UX prompt. For example:
kill -USR1 pid
where pidis the process ID of the mrouteddaemon.
For more information on the routing tables, type man 1M mroutedat the
HP-UX command prompt, and see the EXAMPLE section.
Chapter 2
39
Configuring mrouted
Displaying mrouted Routing Tables
For more information on signals, type man 1M mroutedat the HP-UX
command prompt, and see the Signals section.
40
Chapter 2
Configuring mrouted
Multicast Routing Support Tools
Mu ltica st Rou tin g Su p p or t Tools
This section describes various multicast routing support tools.
Th e m r in fo Tool
mrinfois a multicast routing tool that requests configuration
information from mroutedand prints the information to the standard
output. By default, mroutedprints configuration information for its local
instance. You can override the default request (the local instance of
mrouted) by specifying an alternate router IP address or system name.
For more information, type man 1M mrinfoat the HP-UX command
prompt.
Th e m a p -m bon e Tool
map-mboneis a multicast routing tool that requests multicast router
connection information from mroutedand prints the connection map
information to the standard output. By default (when no alternate router
address is specified), the request message is sent to all the multicast
routers on the local network. If map-mbonediscovers new neighbor
routers from the replies, it sends an identical request to those routers.
This process continues till the list of new neighbors is exhausted.
For more information, type man 1M map-mboneat the HP-UX command
prompt.
Th e n etsta t Tool
You can used netstatto display multicast-related information,
including network statistics and multicast routing table contents.
For more information, type man 1M netstatat the HP-UX command
prompt.
Chapter 2
41
Configuring mrouted
Multicast Routing Support Tools
42
Chapter 2
Configuring gated
contains information about how to configure gatedon various routing
•
•
•
•
•
•
•
•
•
•
“Specifying Route Preference” on page 94
“Importing and Exporting Routes” on page 97
“Starting gated” on page 99
“Troubleshooting gated” on page 101
For additional information on gated, type man 1M gated.confat the
HP-UX prompt.
44
Chapter 3
Configuring gated
Configuration Overview
Con figu r a tion Over view
Upon startup, gatedreads the configuration file to decide how each
protocol must be used to manage routing. By default, it uses the
configuration file named/etc/gated.conf. Creating the configuration
file is usually the responsibility of the system administrator.
The configuration file can include up to eight sections (called cla sses) of
configuration sta tem en ts. You can define the statements further with
optional cla u ses. The eight classes of configuration statements are:
•
Directives — Directives are statements that are immediately acted
upon by the gatedparser.
•
•
•
•
Trace — Trace statement controls gatedtracing options.
Options — Options statements define global gatedoptions.
Interface — Interface statements define router interface options.
Definition — Definition statements identify the autonomous system
that the router belongs to and m a r tia n addresses (addresses for
which routing information must be ignored).
•
•
•
Protocol — Protocol statements enable or disable gatedprotocols
and set protocol options.
Static — Static statements define static routes or default routers
that are installed in the kernel routing table.
Control — Control statements define routes that are imported to the
router from other routing protocols, and paths that the router
exports to other routing protocols.
For a description of each configuration class and to determine which
statements belong to which class, type man 4 gated.confat the HP-UX
prompt.
With Version 3.5.9 of gated, the two statements previously in the Trace
class (tracefileand traceoptions) have been combined into a single
traceoptionsstatement. Therefore, the tracefilestatement has been
eliminated. Also, some of the global options have been removed, some
new global options have been added, and options have been added for
some of the protocols. For details about the new syntax, type man 4
gated.confat the HP-UX prompt.
Chapter 3
45
Configuring gated
Configuration Overview
10.30, and do not have any tracing configured in your gated3.0
/etc/gated.confconfiguration file, you can continue to use your 3.0
configuration file with gated3.5.9. If you do have tracing configured in
your gated3.0 file, you must run the conv_configconversion tool on the
file so that it follows the 3.5.9 syntax (see “Converting the Configuration
File from 3.0 to 3.5.9” on page 48). For more information about the 3.5.9
syntax, type man 4 gated.confat the HP-UX prompt.
To check your gated3.0 configuration file for compatibility with the 3.5.9
syntax, issue the following command at the command prompt:
gated -c [-f config_file_name]
You need to specify -f config_file_nameonly if the configuration file
you are checking is not the default file.
If you are still running gated2.0, you must manually edit the
/etc/gated.conffile so that it follows the 3.5.9 syntax. The conversion
utility that was previously available to migrate from gated2.0 to 3.0 is
no longer available, and you can only use the conv_configtool when
migrating from 3.0 to 3.5.9.
Con figu r in g ga ted
To configure gated, complete the following steps:
1. Issue the following command to create the gatedconfiguration file
/etc/gated.conf:
gdc newconf
If the protocols are not explicitly specified, gatedassumes the
following:
rip yes;
ospf no;
the appropriate statements for each protocol to the
/etc/gated.confconfiguration file.
See the section “Configuring the OSPF Protocol” on page 60 for
OSPF routing configuration statements. RIP configuration is
described in “Configuring the RIP Protocol” on page 50. For a more
detailed description of the configuration statements, type man 4
gated.confat the HP-UX prompt.
46
Chapter 3
Configuration Overview
3. Add statements for any additional configuration information. See
“Customizing Routes” on page 90, “Specifying Tracing Options” on
page 92, and “Specifying Route Preference” on page 94 for other
configuration options.
In particular, you may want to prevent gatedfrom deleting
interfaces from the routing table when gateddoes not receive
routing protocol information from that interface. To do this, insert
passive interface definitions in the interfacesstatements. For
example:
interfaces {
interface all passive ;
} ;
:
:
<protocol statements follow>
4. If you normally use default routes, you must configure a static
default route in the gatedconfiguration file. If the default route is a
gateway node, add the following entry to /etc/gated.conf(enter
the gateway node’s IP address for gateway_IP_Address):
static {
default gateway gateway_IP_Address retain ;
} ;
The default route may be a local interface, such as in topologies that
include a proxy ARP server on the local network. If the default route
is a local interface, add the following entry to /etc/gated.conf:
static {
default interface local_IP_Address retain ;
} ;
the local address of the interface attached to the same network as the
proxy ARP server.
See “Customizing Routes” on page 90 and the section covering
“Common Problems” on page 104 in the section “Troubleshooting
gated” on page 101 for more information.
5. To check for syntax errors in the configuration file, run gatedwith
the -cor -Coption (gatedexits after parsing the configuration file).
Chapter 3
47
Configuring gated
Configuration Overview
NOTE
You can also use the command gdc checkconfto parse the
/etc/gated.conffile for syntax errors. gdcissues a message to
indicate the parsing errors. If there are any errors, the error output
is saved to a file for further inspection. For more details, type man 1M
gdcat the HP-UX prompt.
6. Set the environment variable GATEDto 1in the file
/etc/rc.config.d/netconfto invoke gatedautomatically when
the system is started.
7. To start gated, reboot your system or run the following gated
startup script:
/sbin/init.d/gated start
You can also start gatedby executing the following command:
gdc start
The following message appears:
gated started, pid 25579
where
25579is the process ID (pid) of the gated process.
Examples of gatedconfiguration files are included in the sections
“Configuring the OSPF Protocol” on page 60 and “Configuring the RIP
Protocol” on page 50. Additionally, they are also included in the
/usr/newconfig/gated/confdirectory.
NOTE
HP recommends that you specify the IP address in dot notation (for
example, a.b.c.d) for a configuration option such as a router, host, or
interface. Host names with multiple IP addresses associated with them
produce errors.
Con ver tin g th e Con figu r a tion File fr om 3.0 to 3.5.9
To convert a gated3.0 configuration file to the gated3.5.9 syntax,
complete the following steps:
48
Chapter 3
Configuring gated
Configuration Overview
1. Retain a copy of the gated3.0 configuration file, because you cannot
specify the same file for input and output while running the
conv_configconversion tool. For example, if you are using
/etc/gated.conffor 3.0, type the following command:
cp /etc/gated.conf /etc/gated.conf.30
2. Issue the following command at the HP-UX prompt:
conv_config < input_config_file_name > output_config_file
where
input_config_file_nameis the name of the gated3.0 file you want
to convert. You must specify this name, because the tool does not
assume that you are converting the default file, /etc/gated.conf.
output_config_fileis the name of the new configuration file for
gated3.5.9. You must specify this name, because the tool does not
assume that you are coverting the default file, /etc/gated.conf.
3.5.9, issue the following command:
conv_config < /etc/gated.conf.30 > /etc/gated.conf
After running the conversion tool, you can check the new configuration
file for compatibility using the gated -ccommand. See the Note in the
section “Configuration Overview” on page 45 for more information.
Chapter 3
49
Configuring gated
Configuring the RIP Protocol
Con figu r in g th e RIP P r otocol
RIP uses h op cou n t to determine the shortest path to a destination.
Hopcount is the number of routers a packet must pass through to reach
its destination. If a path is directly connected, it has the lowest hopcount
of 1. If the path passes through a single router, the hopcount increases to
2. Hopcount can increase to a maximum value of 16, which is RIP’s
in fin ity m etr ic, an indication that a network or node cannot be reached.
If gatedencounters an unreachable node, it goes into Hold d ow n Mode.
Holddown Mode stops a node from propagating routing information until
the other nodes that it is communicating with stabilize their routing
information.
Hosts with only one LAN interface may use the RIP protocol with gated
to passively listen to routing information when multiple routers on the
LAN exist. If only one router on the LAN exists (leaving only one path off
the local LAN), you can configure a static route to that router in the
/etc/rc.config.d/netfile, or issue the routecommand manually,
instead of running gated.
In certain cases, you may not want the traffic to follow a certain path,
because it incurs an unacceptable cost or security risk. In these cases,
gatedallows you to assign a metric to each interface. This allows you to
select or bypass a path, irrespective of its length or speed.
RIP P r otocol Sta tem en t
The syntax of the RIP protocol statement is as follows:
rip yes|no | on|off [ {
broadcast|nobroadcast ;
nocheckzero ;
preference preference ;
defaultmetric metric ;
query authentication [none|[[simple|md5] password]] ;
interface interface_list
[noripin]|[ripin] [noripout]|[ripout]
[metricin metric] [metricout metric]
[version 1]|[version 2 [multicast|broadcast]]
[[secondary] authentication [none|[simple|md5] password]
] ;
[interface ...]
50
Chapter 3
Configuring gated
Configuring the RIP Protocol
trustedgateways router_list ;
sourcegateways router_list ;
traceoptions traceoptions ;
} ] ;
Curly braces ({}) are part of the syntax for the RIP protocol statement.
Square brackets ([]) are not part of the syntax; they are used here to
indicate optional parameters.
yes(or on) informs gatedto enable the RIP protocol at this node and to
process RIP packets coming in from other nodes. no(or off) informs
gatedto disable the RIP protocol at this node. If gatedfinds fewer than
two network interfaces, the node listens to RIP information. If gated
finds two or more network interfaces, the node not only listens but also
broadcasts or multicasts the RIP information. If you do not specify a RIP
statement in your configuration file, rip onis assumed.
The following describes the various options in the RIP statement:
• broadcastspecifies that RIP packets are always generated. If the
RIP protocol is enabled and more than one interface is specified,
broadcastis assumed. Specifying broadcastwith only one interface
is useful only when propagating static routes or routes learned from
other protocols.
• nobroadcastspecifies that RIP packets are sent only to routers
listed in the sourcegatewaysclause. If the RIP protocol is enabled,
but only one interface is specified, nobroadcastis assumed.
• nocheckzerospecifies that the RIP protocol must not check whether
the reserved fields in the RIP packets are zero. In RIP Version 1 (as
described in RFC 1058), certain reserved fields must be zero;
however, this may vary in RIP implementations.
• preferencedetermines the order of routes from other protocols to
the same destination in the routing table. gatedallows one route to a
destination per protocol for each autonomous system. In case of
multiple routes, the route used is determined by the value of
preference.
Defa u lt: 100
Ra n ge: 0 (most preferred) – 255 (least preferred)
• defaultmetricis the default metric used when propagating routes
learned from other protocols.
Defa u lt: 16
Chapter 3
51
Configuring gated
Configuring the RIP Protocol
Ra n ge: 1 – 16
• query authentication [none|[[simple|md5] password]]
specifies the authentication, if any, that is required for query packets
that do not originate from routers. If authentication consisting of
only a password is required, specify simple passwordor password.
If the required authentication consists of a key that was created with
the MD5 algorithm, specify md5. Default: none.
• interfaceis specified as one of the following (in the order of
precedence): an IP address (for example, 193.2.1.36), a domain or
interface name (for example, lan0or lan1), a wildcard name (for
example, lan*), or all(which refers to all interfaces). You can
specify multiple interfacestatements with different clauses. If you
specify a clause more than once, the instance with the most specific
interface reference is used.
• noripinspecifies that gateddoes not process any RIP information
received through the specified interface. Default: ripin.
• noripoutspecifies that gateddoes not send any RIP information
through the specified interface. Default: ripout.
• metricinspecifies the incoming metric for all routes propagated to
this node through the specified interface.
Defa u lt: kernel interface metric plus 1 (the default RIP
hopcount)
• metricoutspecifies the outgoing metric for all routes propagated by
this node through the specified interface.
Defa u lt: 0
• version 1specifies that RIP Version 1 packets (as defined in RFC
1058) are sent; RIP Version 2 packets (defined in RFC 1388) are sent
only in response to a Version 2 poll packet. version 2specifies that
RIP Version 2 packets are sent to the RIP multicast address or to the
broadcast addresses. You can specify how the packets are sent with
the multicastor broadcastclauses. version 2 multicastimplies
that you want to send Version 2 packets (containing subnet mask
information). version 2 broadcastimplies that you want to send
Version 2 packets. If you do not specify a version, version 1is
assumed.
52
Chapter 3
Configuring gated
Configuring the RIP Protocol
• [secondary] authentication [none|[simple|md5] password]
specifies the type of authentication for RIP Version 2 packets (it is
ignored for Version 1 packets). secondaryindicates that the
secondary authentication is defined; otherwise, the primary
authentication is defined. If authentication consisting of only a
password is required, specify simple passwordor password(where
passwordis a quoted string of 0 – 16 characters). If the required
authentication consists of a key that was created with the MD5
algorithm, specify md5. Default: none. (If you do not specify the
authenticationclause, the default is primary authentication of
noneand no secondary authentication.
• trustedgatewaysprovides a list of routers that provide valid RIP
routing information; routing packets from other routers are ignored.
• sourcegatewaysspecifies routers to which you can send RIP routing
packets. If you specify the nobroadcastclause, routing updates are
sent only to routers listed in the sourcegatewaysclause.
• traceoptionsenables tracing for the RIP protocol. See “Specifying
Tracing Options” on page 92.
Con figu r a tion Op tion s
The -eand -aconfiguration options help increase the RIP convergent
time on the HP-UX operating system. You can set these command-line
options in the /etc/gated.conffile under the RIP protocol statement.
The -eoption specifies route_expiry_time, which is the expiration time
used by RIP to determine route aging. The minimum value is 1 second,
and the maximum value is 180 seconds. The default value is 180 seconds.
Using the -aoption, you can specify the route_update_timeoption.
route_update_timeis the time in seconds required by the RIP protocol
to send RIP updates to other nodes on the network. The minimum value
is 1 second, and the maximum value is 30 seconds. The default value is
30 seconds.
Alternatively, you can manually change the value in the
/etc/gated.conffile. You can specify the -eand -aoptions either on
the command line or in the configuration file. Configuration file options
override the command-line options.
Chapter 3
53
Configuring gated
Configuring the RIP Protocol
Sim p le RIP Con figu r a tion
A simple RIP configuration consists of RIP routers and end nodes that
listen to information exchanged by the RIP routers, as shown in
Figure 3-1.
Figure 3-1 and the accompanying text describe configuration of a single
end system (node A) and a RIP router (node B). The configuration is the
same for multiple end systems and RIP routers (only node B’s
configuration is shown here). This example shows only the syntax needed
for a simple configuration. A detailed description of the entire RIP
protocol statement is given after this example.
Figu r e 3-1
Exa m p le of Sim p le RIP Con figu r a tion
. . .
A
End Systems
121.1.0.10
B
. . .
RIP
Routers
A: En d System on a LAN w ith RIP Rou ter s
Set up the configuration file /etc/gated.confin the end system A as
follows:
rip yes {
interface 121.1.0.10 version 2 multicast;
};
static {
default interface 121.1.0.10 preference 255 ;
};
54
Chapter 3
Configuring gated
Configuring the RIP Protocol
With one interface, A can listen to RIP traffic on the network but does
not forward routing information. Routers must be multicasting RIP
packets on this network for A to learn about them and update its routing
table. The first syntax statement enables RIP on node A’s interface
(121.1.0.10) to multicast routing information. The second statement
specifies a static local default route to prevent gatedfrom deleting it.
B: RIP Rou ter
Set up /etc/gated.confas follows:
rip yes {
interface all version 2 multicast ;
};
This enables the RIP protocol to multicast routing information on all
interfaces.
Exa m p le of a La r ge RIP Con figu r a tion
Figure 3-2 and the accompanying text describe how to configure gated
for the RIP protocol in each node within a networked system.
B, D, and E pass routing information among themselves and update their
routes accordingly. C listens to the RIP conversation between B, D, and
E, and updates its routes accordingly. If both the routers D and E can
provide a path to a network, but the path through router D is shorter,
nodes B, C, and E use router D when routing packets to that network. If
D goes down, E becomes the new router to that network for the nodes B,
C, and E.
Chapter 3
55
Configuring gated
Configuring the RIP Protocol
Figu r e 3-2
Exa m p le of La r ge RIP Netw or k
D: Major Router
A: Cluster Node
or
Isolated Node
134.5.0.1
A
133.4.0.1
121.1.0.2
130.15.0.5
D
130.15.0.0
(network number)
B
132.5.0.1
130.15.0.6
121.1.0.92
B: Root Server
121.1.0.0
(network number)
121.1.0.10
C
C: Single Node
E: Major Router
F: Single Node
F
132.6.0.1
121.1.0.15
E
136.5.0.1
136.5.0.0
(network number)
131.5.0.2
A: Clu ster Nod e (or Isola ted Nod e)
You need not run gatedat this node, because it is on a LAN with only
one router. Set a static default route to the cluster server (B) in the
/etc/rc.config.d/netconffile as follows:
ROUTE_DESTINATION[0]= "default"
ROUTE_GATEWAY[0]= "130.15.0.6"
ROUTE_COUNT[0]= "1"
56
Chapter 3
Configuring gated
Configuring the RIP Protocol
B: Clu ster (or Root) Ser ver Nod e
Run gatedto get routing information about the 121.0.0.0 network. Set
up /etc/gated.confas follows:
interfaces {
interface 130.15.0.6 121.1.0.92 passive ;
};
rip yes {
interface 130.15.0.6 noripout ;
interface 121.1.0.92 version 2 multicast;
};
static {
default gateway 121.1.0.2 preference 255 ;
};
In the previous example, setting ripto yesis similar to setting ripto
broadcast. Both the arguments inform the node to send out RIP
packets, because the node has at least two interfaces. To reduce traffic on
the 130.15.0.0 LAN, use the noripoutoption on this interface. This
prevents RIP from sending packets on the 130.15.0.0 network.
To isolate the 130.15.0.0 LAN, use the following:
export proto rip interface 121.1.0.92 {
proto direct {
130.15.0.0 restrict ;
};
};
To further isolate the LAN from the 121.1.0.0 LAN, do not specify any
static routes that specify that you can reach the LAN through B. See
“Importing and Exporting Routes” on page 97 for more information.
Always specify the passiveoption with the interface’s IP address. It
informs gatedto maintain the routes even if no other nodes on the
121.0.0.0 network are using RIP. Without this clause, gatedchanges the
preference of the route to the interface if it does not receive routing
information for that interface. The static default route adds the specified
default to the kernel routing table. Setting the preferenceto 255
replaces this route whenever another default route is learned from one of
the protocols.
C: En d System on a LAN w ith RIP Rou ter s
Set up /etc/gated.confas follows:
Chapter 3
57
Configuring gated
Configuring the RIP Protocol
rip yes {
interface 121.1.0.10 version 2 multicast;
};
static {
default interface 121.1.0.10 preference 255 ;
};
With one interface, C can listen to RIP traffic on the network but does
not forward routing information. Routers must be multicasting RIP
packets on this network for C to learn about them and to update its
routing table.
D: Ma jor Rou ter
Set up /etc/gated.confas follows:
rip yes {
interface all version 2 multicast ;
};
This runs RIP on all attached networks.
E: Ma jor Rou ter
Set up the configuration file /etc/gated.confas follows:
rip yes {
interface all version 2 multicast;
};
Con tr ollin g RIP Tr a ffic
This section describes configuration options for RIP routing information
sent by gatedfrom the node. Use these options to hide all or part of your
network from other networks or to limit network traffic.
The RIP protocol definition in the /etc/gated.conffile contains the
following two options for limiting RIP routing information exported by
gated:
•
The noripoutclause in the interface definition informs gatednot to
send any RIP information through the listed interfaces.
•
The sourcegatewaysclause informs gatedto send RIP information
directly to the specified routers.
See “RIP Protocol Statement” on page 50 for more information about
these clauses.
58
Chapter 3
Configuring gated
Configuring the RIP Protocol
The options for limiting RIP routing information imported by gatedin
the RIP protocol definition in the /etc/gated.conffile are as follows:
•
The noripinclause in the interface definition informs gatednot to
process RIP information received through the listed interfaces.
•
The trustedgatewaysclause informs gatedto listen to RIP
See “RIP Protocol Statement” on page 50 for more information about
these clauses.
You can also use the gatedimportand exportstatements to restrict
and control the route information propagated from one routing protocol
to another. See “Importing and Exporting Routes” on page 97 for more
information.
Chapter 3
59
Configuring gated
Configuring the OSPF Protocol
Con figu r in g th e OSP F P r otocol
Open Shortest Path First (OSPF) is a link-state routing protocol that
distributes routing information between routers in a single autonomous
system (AS). Each OSPF router transmits a packet with a description of
its local links to all other OSPF routers. The distributed database is built
from the collected descriptions. Using the database information, each
router constructs its own routing table of shortest paths from itself to
each destination in the AS.
OSPF allows you to organize routers, networks, and subnetworks within
an AS into subsets called areas. An area is a grouping of logically
contiguous networks and hosts. Instead of maintaining a topological
database of the entire AS, routers in an area maintain the topology for
only the area in which they reside. Therefore, all routers belonging to an
area must be consistent in their configuration of the area. The topology of
an area is hidden from systems that are not part of the area. The
creation of separate areas can help minimize overall routing traffic in the
AS. Figure 3-3 shows an example of three separate areas defined for an
AS.
60
Chapter 3
Configuring gated
Configuring the OSPF Protocol
Figu r e 3-3
Ar ea s Defin ed in a n Au ton om ou s System
Area 1
Other AS
C
E
D
1
A
B
Legend:
Network
2
3
Router
Area
F
I
Area 2
Area 3
5
Backbone
4
H
G
6
In ter n a l r ou ter s have all their directly connected networks in the same
area. In Figure 3-3, routers A, B, and H are internal routers.
Routers that are connected to multiple areas are called a r ea bor d er
r ou ter s. In Figure 3-3, routers F and G are area border routers.
Routers that connect one AS to another are called AS bou n d a r y
r ou ter s. In Figure 3-3, router D is an AS boundary router.
Neigh bor r ou ter s are routers that interface to a common network.
OSPF uses its own Hello subprotocol to determine which routers are
neighbors. In Figure 3-3, routers A, B, and C are a set of neighbor routers
that interface to network 1, while routers A and F are another set of
neighbor routers that interface to network 2.
NOTE
The Hello subprotocol used with OSPF is not the same as the gated
HELLO protocol. The Hello subprotocol is still supported.
Chapter 3
61
Configuring gated
Configuring the OSPF Protocol
Mu lti-a ccess n etw or k s (networks that can be accessed through two or
more neighbor routers) must have one of the routers identified as a
designated router.
Design a ted r ou ter s initiate OSPF protocol functions on behalf of the
network. In Figure 3-3, you can access network 1 through the neighbor
routers A, B, or C; one of these routers is elected to become the
designated router for network 1.
The set of routers that exchange OSPF protocol packets between areas in
an autonomous system is called the ba ck bon e. In Figure 3-3, routers C,
D, E, F, G, and I form an AS backbone that allows protocol packets to
travel between the three areas.
OSPF routers exchange various types of lin k sta te a d ver tisem en ts to
build their topological databases. Most link state advertisements are
flooded (sent to every router) throughout the attached area. An exception
is the link state advertisement sent out by AS boundary routers that
describe routes to destinations outside the AS; these advertisements are
flooded throughout the AS. Table 3-1 shows the various types of link
state advertisements used by the OSPF protocol.
Ta ble 3-1
Typ es of Lin k Sta te Ad ver tisem en ts
Typ e
Con ten t
Or igin a ted
By
F lood ed
Th r ou gh ou t
Router link Router’s links to
area
Internal and
area border
routers
Area
Network
link
List of routers
attached to network
Designated
router
Area
Area
Summary
link
Routes to
destinations outside
area but within AS
Area border
router
AS
external
link
Routes to
destinations outside
AS
AS boundary
router
AS
AS bou n d a r y r ou ter s exchange routing information with routers in
other autonomous systems. An AS boundary router can be an area
border router or an internal router. It can also be a backbone router, but
62
Chapter 3
Configuring gated
Configuring the OSPF Protocol
it is not required that an AS boundary router be a backbone router. An
AS boundary router learns about routes other than its attached AS
through exchanges with other routing protocols or through configuration
information. Each AS boundary router calculates paths to destinations
outside of its attached AS. It then advertises these paths to all routers in
its AS.
Following are the two levels of routing in an AS:
•
In tr a -a r ea r ou tin g, where the source and destination of a packet
both reside in the same area. Routing is handled by internal routers.
•
In ter -a r ea r ou tin g, where the source and destination of a packet
reside in different areas. Packets travel through an intra-area route
from the source to an area border router, then travel an inter-area
route on a backbone path between areas. Finally, they travel another
intra-area route to the destination.
P la n n in g You r OSP F Con figu r a tion
Following is a suggested sequence of steps in planning the OSPF routing
in your autonomous system:
1. If your AS exchanges routing information with other autonomous
systems, you need to obtain a unique AS number from the Internet
Assigned Numbers Authority.
2. Partition the AS into areas. You can partition any interconnected
networks into lists of address ranges, with each address range
represented as an address-mask pair. The area border routers
summarize the area content for each address range and distribute
the summaries to the backbone. See “The networks Statement” on
page 66 for more information on specifying address ranges.
3. Identify the internal routers for each area. An internal router
configuration contains only one area definition.
interface. The configuration for each area border router contains
multiple area definitions.
5. For each router, determine the interface type for each area. Router
interfaces can be multicast, non-broadcast multi-access (NBMA), or
point-to-point. See “The interface Statement” on page 67 for more
information on router interfaces.
Chapter 3
63
Configuring gated
Configuring the OSPF Protocol
networks, several routers can be designated router candidates.
Designated routers are specified in the interface definitions (see “The
interface Statement” on page 67).
7. You must decide if you want to assign a cost to each interface. See
“Cost” on page 79 for more information about costs.
8. Designate stub areas. AS external link advertisements are
in the configured stub areas. See “Stub Areas” on page 74 for more
information
“Defining Backbones” on page 76 for more information
10. Determine if routing packets are authenticated for each area. See
“Authentication” on page 77 for more information
11. Identify AS boundary routers. See “AS External Routes (AS
Boundary Routers Only)” on page 80 for more information.
En a blin g OSP F
The default router identifier used by OSPF is the address of the first
interface on the router encountered by gated. To set the router identifier
to a specific address, specify the routeridinterface statement in the
Definition class of the /etc/gated.conffile.
NOTE
You must enable the OSPF protocol only for routers. When the OSPF
protocol is enabled for a system, the system is treated as a router, and
not a host, by other hosts.
You can enable the OSPF protocol using the ospfstatement in the
Protocol class of the /etc/gated.conffile. The clause yes(or on)
informs gatedto enable the OSPF protocol at this node and to process all
OSPF packets arriving from other nodes. If you do not specify an OSPF
line in your configuration file, ospf nois assumed. The clause no(or
off) informs gatedto disable the OSPF protocol on this node.
The following is an example to enable OSPF:
ospf yes { ... }
64
Chapter 3
Configuring gated
Configuring the OSPF Protocol
The following sections explain other statements defined for the OSPF
protocol configuration.
Defin in g Ar ea s
Each OSPF router is associated with one or more areas. The area
statement identifies an OSPF area. The value is in the form of a dotted
quad, or a number between 1 and 4294967295. To define an area, you
must specify the following:
•
•
The addresses of the networks that make up the area.
The router interfaces used to communicate with the area.
The configuration of an area border router contains multiple area
definitions; a different router interface is defined for each area.
Figure 3-4 shows an example of an area border router that is connected
to area 0.0.0.1 through interface 193.2.1.33 and to area 0.0.0.2 through
interface 193.2.1.17.
Figu r e 3-4
Ar ea Bor d er Rou ter Con figu r a tion Exa m p le
Area 0.0.0.1
Area 0.0.0.2
Area
Border
Router
193.2.1.33
to Network A
193.2.1.17
to Network B
The following is an example of the area definitions in the router’s
/etc/gated.conffile:
ospf yes {
area 0.0.0.1 {
interface 193.2.1.33 {
...
} ;
} ;
area 0.0.0.2 {
interface 193.2.1.17 {
...
} ;
} ;
} ;
Chapter 3
65
Configuring gated
Configuring the OSPF Protocol
You can define various characteristics for an area and interfaces. The
following sections describe the configuration statements that you can use
in defining an area.
Th e n etw or k s Sta tem en t
The networksstatement defines the address ranges that forms an OSPF
area. This definition applies only to area border routers, where multiple
areas are specified, and is required only if you need to compress a
number of subnets using a network mask.
A network address followed by a hexadecimal bit mask specifies an IP
address range in the networkstatement. For example, the following
address range begins with the network address 193.2.1.16 and includes
the first 15 addresses in that network (193.2.1.17 through 193.2.1.31):
193.2.1.16 mask 0xfffffff0
You can specify many separate networks in an address range. Area
border routers advertise a single route for each address range.
Figure 3-5 shows an example of a router that is connected to area 0.0.0.1
through the interface 193.2.1.33. The attached network consists of
addresses 193.2.1.33 through 193.2.1.47. The other network in the area
consists of addresses 193.2.1.17 through 193.2.1.31.
Figu r e 3-5
Area 0.0.0.1
Netw or k Con figu r a tion Exa m p le
193.2.1.33
Router A
193.2.1.17
193.2.1.18
193.2.1.34
193.2.1.35
193.2.1.36
193.2.1.19
. . .
Router B
193.2.1.31
193.2.1.47
. . .
66
Chapter 3
Configuring gated
Configuring the OSPF Protocol
The following is an example of the network definition in the Router A’s
/etc/gated.conffile:
ospf yes
area 0.0.0.1
networks {
193.2.1.16 mask 0xfffffff0 ;
193.2.1.32 mask 0xfffffff0 ;
} ;
interface 193.2.1.33 {
...
} ;
} ;
...
Th e in ter fa ce Sta tem en t
The interfacestatement in the OSPF protocol definition specifies the
interface to use while communicating with the specified networks. You
can specify the interface with an address (for example, 193.2.1.36), a
domain or interface name (for example, lan0or lan1), a wild card name
(for example, lan*), or all(the order of precedence is address, name,
using different clauses. If you specify a clause more than once, the
instance with the most specific interface reference is used.
You can specify the costclause optionally to define a cost of sending a
packet on the interface. This cost is advertised as the link cost for this
interface. See “Cost” on page 79 for more information on setting interface
costs.
You can also enableor disablethe interface definition. If you do not
explicitly specify disable, an interface definition is enabled by default.
OSPF supports the following types of network interfaces:
•
•
A multicast (or broadcast) network is a network that supports two or
more attached routers and allows a single message to be addressed
to a set of network nodes at the same time. An example of a multicast
network is an Ethernet LAN.
A non-broadcast multi-access (NBMA) network is a network that
supports multiple attached routers, but does not support
broadcasting of messages. An example of an NBMA network is an
X.25 PDN.
Chapter 3
67
Configuring gated
Configuring the OSPF Protocol
•
A point-to-point network is a network that joins a single pair of
routers. An example of a point-to-point network is a 56-KB serial
line.
The following sections describe each type of interface.
Mu ltica st In ter fa ces On multicast networks, an OSPF router
dynamically detects its neighbor routers through the OSPF Hello
message. The following statements are defined for a multicast interface:
• retransmitintervalis the number of seconds between
retransmission of link states, database descriptions, and link state
request packets. This value must exceed the expected round-trip
delay between any two routers in the network. A sample value for a
LAN is 5 seconds.
Defa u lt: None (you must specify a value)
Ra n ge: Integer between 0 – 65535
• transitdelayis the number of seconds to transmit a Link State
Update Packet over this interface. This value must take into account
the transmission and propagation delays for the interface. It must be
greater than 0. A sample value for a LAN is 1 second.
Defa u lt: None (you must specify a value)
Ra n ge: Integer between 1 – 65535
• priorityspecifies the priority of the router to be the designated
router. You must configure this value only for interfaces to
multi-access networks. This value specifies the priority of the router
to be the designated router. When two routers attached to a network
attempt to be the designated router, the one with the higher router
priority value takes precedence.
Defa u lt: None (you must specify a value for multi-access networks)
Ra n ge: 8-bit unsigned integer between 0 – 255. 0 means that the
router is ineligible to become a designated router on the attached
network.
• hellointervalspecifies the time interval (in seconds) for the
transmission of OSPF Hello packets. Smaller intervals ensure that
changes in network topology are detected faster. A sample value for
an X.25 network is 30 seconds. A sample value for a LAN is 10
seconds.
68
Chapter 3
Configuring gated
Configuring the OSPF Protocol
Defa u lt: None (you must specify a value)
Ra n ge: Integer between 0 – 255
NOTE
The hellointervalvalue must be the same for all OSPF routers.
• routerdeadintervalspecifies the time interval (in seconds) for
which the Hello packets are not received from a router before it is
considered down or inactive by its neighbors. This value must be a
multiple of the hellointervalvalue.
Defa u lt: None (you must specify a value)
Ra n ge: 0 – 65535
NOTE
The routerdeadintervalvalue must be the same for all OSPF
routers.
•
You can use the password authkeyto validate the protocol packets
received on the router interface. The value can be 1 to 8 decimal
digits separated by periods, a 1-byte to 8-byte hexadecimal string
preceded by 0x, or a string of 1 to 8 characters in double quotes.
Defa u lt: None
Ra n ge: Up to 8 bytes
NOTE
To set an authkeyvalue, you must set the authtypeclause to 1or
simplefor the area. See “Authentication” on page 77 for more
information on using OSPF authentication.
Chapter 3
69
Configuring gated
Configuring the OSPF Protocol
Figure 3-6 shows an example of a router that is connected to a multicast
network through the interface 193.2.1.35.
Figu r e 3-6
Mu ltica st Rou ter In ter fa ce Exa m p le
Router
193.2.1.35
Router
Network
Network
Network
The following is an example of the multicast interface definition in the
router’s /etc/gated.conffile:
interface 193.2.1.35 cost 5 {
enable ;
priority 15 ;
hellointerval 5 ;
routerdeadinterval 20 ;
retransmitinterval 10 ;
} ;
Non -Br oa d ca st Mu lti-Access (NBMA) In ter fa ce On NBMA
networks, you must supply the configuration information, including the
routers that are attached to the network, so that the OSPF’s Hello
protocol communicates with neighbor routers. An NBMA interface
definition applies to both X.25 network interfaces and systems that do
not support IP multicasting. You can define an NBMA interface using the
multicast interfacestatements, with the following additions:
•
You must specify the clause nonbroadcastin the interface
statement.
• pollintervalspecifies a rate at which hellos are sent when a
neighboring router becomes inactive (a router is considered inactive
when hellos are not received from the router for the amount of time
70
Chapter 3
Configuring gated
Configuring the OSPF Protocol
specified by the routerdeadintervaldefinition). The value of
pollintervalmust be larger than the value of hellointerval. A
sample value for an X.25 network is 2 minutes.
Defa u lt: None (you must specify a value)
Ra n ge: 0 – 255
• routersspecify the list of routers attached to the non-broadcast
network. Routers are defined by their IP interface addresses. You
must define the routers that are eligible to be designated routers as
eligible.
Figure 3-7 shows an example of a router (A) that is connected to an
NBMA network through the interface 193.2.1.35. Two other routers are
also attached to the network: router B is connected through the interface
193.2.1.33 and C is connected through the interface 193.2.1.46. B and C
are eligible to be designated routers.
Figu r e 3-7
Non -Br oa d ca st Rou ter In ter fa ce Exa m p le
Router
A
Network
193.2.1.35
Network
Router
B
Router
C
Internet
193.2.1.46
193.2.1.33
Network
Network
The following is an example of the non-broadcast interface definition in
router A’s /etc/gated.conffile:
Chapter 3
71
Configuring gated
Configuring the OSPF Protocol
interface 193.2.1.35 nonbroadcast cost 5 {
routers {
193.2.1.33 eligible ;
193.2.1.46 eligible ;
} ;
priority 15 ;
hellointerval 5 ;
routerdeadinterval 20 ;
retransmitinterval 10 ;
pollinterval 20 ;
} ;
Poin t-to-Poin t In ter fa ces On point-to-point networks, an OSPF
router dynamically detects its neighbor router by sending OSPF Hello
packets. The following statements are defined for a point-to-point
interface:
• retransmitintervalis the time interval (in seconds) between the
retransmission of link states, database descriptions, and link state
request packets. This value must exceed the expected round-trip
delay between any two routers in the network. A sample value for a
LAN is 5 seconds.
Defa u lt: None (you must specify a value)
Ra n ge: 0 – 65535
• hellointervalspecifies the time interval (in seconds) between
transmission of OSPF Hello packets. Smaller intervals ensure that
changes in network topology are detected faster. A sample value for
an X.25 network is 30 seconds. A sample value for a LAN is 10
seconds.
Defa u lt: None (you must specify a value)
Ra n ge: 0 – 255
NOTE
The hellointervalvalue must be the same for all OSPF routers.
72
Chapter 3
Configuring gated
Configuring the OSPF Protocol
• routerdeadintervalspecifies the time interval (in seconds) for
which the Hello packets are not received from a router before it is
considered down or inactive by its neighbors. This value must be a
multiple of the hellointervalvalue.
Defa u lt: None (you must specify a value)
Ra n ge: 0 – 65535
NOTE
The routerdeadintervalvalue must be the same for all OSPF
routers.
You can define a point-to-point interface with or without a
nonbroadcastclause. If you specify the nonbroadcastclause, then
you must define the pollintervalstatement.
• pollintervalspecifies a rate at which hellos are sent when a
neighboring router becomes inactive (a router is considered inactive
when hellos have not been received from the router for the amount of
time specified by the routerdeadintervaldefinition). The value of
pollintervalmust be larger than the value of hellointerval. A
sample value for an X.25 network is 2 minutes.
Defa u lt: None (you must specify a value)
Ra n ge: 0 – 255
If the device at the other end of the point-to-point network is not an
OSPF router, you can prevent sending Hello packets to that OSPF
router using the stubhostsstatement. stubhostsspecifies the IP
address or domain name of the non-OSPF host. The cost of sending a
packet to the host must also be specified (in most cases, the host has
only a single connection to the network, so the cost configured has no
effect on routing).
Chapter 3
73
Configuring gated
Configuring the OSPF Protocol
Figure 3-8 shows an example of a router (A) that is connected to a
non-broadcast, point-to-point network through interface 193.2.1.1.
Figu r e 3-8
Poin t-to-Poin t Rou ter In ter fa ce Exa m p le
Router
B
Router
A
193.2.1.1
193.2.1.2
The following is an example of the interface definition in router A’s
/etc/gated.conffile:
interface 193.2.1.1 nonbroadcast cost 5 {
hellointerval 30 ;
routerdeadinterval 30 ;
retransmitinterval 30 ;
pollinterval 30 ;
} ;
If the router A is connected to a multicast, point-to-point network, you
must omit the nonbroadcastclause and the pollintervalstatement.
Stu b Ar ea s
By default, AS external link advertisements (routes to destinations
outside the AS) are propagated to every router in every area in the AS.
You can configure certain OSPF areas as stub areas. AS external link
advertisements are not flooded through stub areas. This reduces the size
of the topology database that must be maintained by internal routers in
the stub area and reduces the protocol traffic through the area. For
example, if all the inter-area traffic for an area must go through a single
router, then it is not necessary for all routers in the area to receive
inter-area routing information.
An area border router advertises a default route in the stub area as the
summary of all the IP destinations that are reachable outside the AS.
Summary link advertisements (routes to destinations outside the area
but within the AS) are still sent into the stub area.
The stubstatement specifies that the area is a stub area. You can
optionally define a costclause to specify the cost associated with the
default route that is advertised in the stub area.
74
Chapter 3
Configuring gated
Configuring the OSPF Protocol
Figure 3-9 shows an example of an area border router that is connected
to area 0.0.0.2 through interface 193.2.1.20. Because all traffic in and out
of the area 0.0.0.2 must pass through router A, it is not necessary for the
area’s internal routers, such as router B, to receive inter-area routing
information.
Figu r e 3-9
Area 0.0.0.1
Ar ea Bor d er Rou ter Con figu r a tion Exa m p le
Area 0.0.0.2
193.2.1.16 mask 0xfffffff0
Router
193.2.1.17
B
Router
A
193.2.1.20
193.2.1.18
193.2.1.19
The following is an example of the stub area definition in the router’s
/etc/gated.conffile:
OSPF yes {
area 0.0.0.2 {
stub cost 5 ;
networks {
193.2.1.16 mask 0xfffffff0 ;
} ;
interface 193.2.1.20 nonbroadcast cost 5 {
enable ;
routers {
193.2.1.17 eligible ;
} ;
priority 5 ;
hellointerval 5 ;
routerdeadinterval 20 ;
retransmitinterval 10 ;
pollinterval 20 ;
} ;
} ;
} ;
Chapter 3
75
Configuring gated
Configuring the OSPF Protocol
Defin in g Ba ck bon es
The OSPF backbone distributes routing information between areas. You
can define backbones with the same statements and clauses as areas.
You need not define the stubstatement for a backbone. The backbone
statement is used to define a router as a backbone router. If an OSPF
internal or area boarder router is also a backbone router, the backbone
statement must follow the areastatements in the /etc/gated.conffile.
Whenever you configure an area border router (a router connected to
multiple areas), you must provide the backbone.
Figure 3-10 shows an example of two area border routers that form part
of a backbone. Router A has interfaces to both area 0.0.0.1 and area
0.0.0.2, while router B has interfaces to areas 0.0.0.3 and 0.0.0.4. Router
A is connected to router B through interface 15.13.115.156.
Figu r e 3-10
Area 0.0.0.1
Ba ck bon e Con figu r a tion Exa m p le
Area 0.0.0.3
15.13.115.156
Router A
Router B
Area 0.0.0.2
Area 0.0.0.4
The following is an example of the backbone router definition in router
A’s /etc/gated.conffile:
76
Chapter 3
Configuring gated
Configuring the OSPF Protocol
backbone {
interface 15.13.115.156 {
enable ;
transitdelay 20 ;
priority 20 ;
hellointerval 30 ;
routerdeadinterval 120 ;
retransmitinterval 60 ;
} ;
} ;
If the router is directly attached via a point-to-point interface to a host
that is not running OSPF, you can prevent sending OSPF Hello packets
to the host. Do this by specifying the subhoststatement with the host’s
address. You can optionally define the cost.
NOTE
Backbones must be directly connected or contiguous. In some gated
implementations, you can configure a virtual link to join non-contiguous
backbone routers. HP-UX systems do not support virtual links.
Au th en tica tion
The OSPF protocol allows you to authenticate packets containing routing
information. You can configure the authentication on a per-area basis;
You can use different authentication methods in different areas.
gatedsupports a simple password authentication method. You can also
choose to have no authentication. You can use the authtypestatement to
define the authentication method used for the area. 0or nonespecifies
that routing exchanges in the area are not authenticated. 1or simple
specifies that network passwords of up to 64 bits (8 characters) are used
to authenticate packets received from routers in the area.
In the simple password authentication method, all routers that interface
to a given network use the same password. The password is defined by
the authkeystatement in the router’s interface definition. If you do not
configure a router with the same password as other routers in the
network, other networks discard the router’s packets. The password is
Chapter 3
77
Configuring gated
Configuring the OSPF Protocol
configured on a per-interface basis. If a router has interfaces to more
than one network, different passwords can be configured. This is
illustrated in Figure 3-11.
Figu r e 3-11
Sim p le Pa ssw or d Au th en tica tion
A
LAN 1
authkey "travis"
B
authkey "pepe"
LAN 2
C
The following example shows an authtypestatement that enables a
simple password authentication for the routers in the area and an
authkeystatement in the interface definition that defines a password
(travis) to validate protocol packets received by the router:
area 0.0.0.1 {
authtype simple ;
networks {
193.2.1.16 mask 0xfffffff0 ;
193.2.1.32 mask 0xfffffff0 ;
} ;
interface 193.2.1.35 nonbroadcast cost 5 {
routers {
193.2.1.33 eligible ;
193.2.1.46 eligible ;
} ;
priority 15 ;
enable ;
hellointerval 5 ;
routerdeadinterval 20 ;
78
Chapter 3
Configuring gated
Configuring the OSPF Protocol
retransmitinterval 10 ;
pollinterval 20 ;
authkey " travis " ;
} ;
} ;
Cost
The outbound side of each router interface is associated with a
configurable cost. Lower cost interfaces are more likely to be used in
forwarding data traffic. Cost values are assigned at the discretion of the
network or system administrator. While the value is arbitrary, it must be
a function of throughput or capacity of the interface: the higher the
value, the lower the throughput or capacity. Thus, the interfaces with the
highest throughput or capacity must be assigned lower cost values than
other interfaces. Interfaces from networks to routers have a cost of 0.
Figure 3-12 shows an example network where costs are specified for each
interface.
Figu r e 3-12
Cost Con figu r a tion Exa m p le
A
193.2.1.35 (cost 5)
LAN 1 193.2.1.32
193.2.1.33 (cost 5)
193.2.1.46 (cost 10)
193.2.1.30 (cost 10)
B
C
193.2.1.17 (cost 5)
LAN 2 193.2.1.16
193.2.1.20 (cost 5)
D
Chapter 3
79
Configuring gated
Configuring the OSPF Protocol
In Figure 3-12, there are two possible packet routes between nodes A and
D: one route goes through node B and the other route goes through node
C. The cost of each route is calculated as follows:
Node A to node B and node B to node D: 5+5 = 10
Node A to node C and node C to node D: 5+10 = 15
The lowest cost OSPF path between nodes A and D is therefore through
node B. However, packets are rerouted through node C if there is a link
failure between node B and LAN 2.
You can optionally define costin the following places in the
/etc/gated.conffile:
•
In a defaultsstatement in the OSPF protocol configuration, which
applies only to AS boundary routers. This cost definition applies to
routes to destinations outside the AS. These routes may have been
derived from other routing protocols, such as EGP. See “AS External
Routes (AS Boundary Routers Only)” on page 80 for more
information.
•
In the exportstatement in the Control class in the
/etc/gated.conffile, which applies only to AS boundary routers.
This cost definition applies to routes that are exported from the AS
boundary router to routers in other autonomous systems.
•
•
•
In the stub area definition of the OSPF protocol configuration. This
cost definition specifies the cost of the default summary link that is
advertised in the area.
In the stubhostsdefinition of the OSPF protocol configuration. This
cost definition specifies the cost of a point-to-point interface between
the router and a non-OSPF host.
In the subhostsdefinition of the OSPF protocol configuration. This
cost definition specifies the cost of a point-to-point interface between
the backbone router and a non-OSPF host.
AS Exter n a l Rou tes (AS Bou n d a r y Rou ter s On ly)
AS exter n a l (ASE) routes are paths to destinations that are outside the
AS. Most ASE routes are routes to specific destinations. AS boundary
routers specify the ASE routes through another routing protocol, such as
EGP, or through configured routes.
80
Chapter 3
Configuring gated
Configuring the OSPF Protocol
gatedsupports the use of route information from other autonomous
systems that use other routing protocols, such as EGP. AS boundary
routers send AS external link advertisements and flood the AS with
advertisements (with the exception of configured stub areas). A single AS
external link advertisement is sent for each external route that the AS
boundary router has learned about.
Externally defined routing information and OSPF routing information
are maintained separately. In addition, you can tag the externally
information along with the route information.
Statements in the Control class of the /etc/gated.conffile control the
importing of routes from routing protocols to a gatedforwarding table
and the exporting of routes from the gatedforwarding table. See
“Importing and Exporting Routes” on page 97 for more information.
You must specify the defaultsstatements in the OSPF protocol
configuration only for AS boundary routers. These statements specify
how external routing information is handled by the OSPF protocol. You
can define the following in the defaultsstatements:
imported from other autonomous systems. The preferencevalue
determines the order of routes to the same destination in the routing
table. gatedallows one route to a destination per protocol for each
AS. In case of multiple routes, the route used is determined by the
lowest preferencevalue (see “Specifying Route Preference” on
page 94 for more information). If a preference value is not specified,
ASE routes are imported with a preference of 150.
Defa u lt: 150
Ra n ge: 0 (most preferred) – 255 (least preferred)
• costspecifies the cost associated with an OSPF route that is
exported to other AS boundary routers.
Defa u lt: 0
Ra n ge: 0 – 65535
• tagspecifies an OSPF tag placed on all routes exported by gated
into OSPF. You can tag each external route by the AS boundary
router to identify the source of the routing information. The tag
Chapter 3
81
Configuring gated
Configuring the OSPF Protocol
value can be an unsigned 31-bit number. You can also specify tagas
as_tag, where as_tagis an unsigned 12-bit number that is
automatically assigned.
• typedetermines how ASE routes imported into OSPF are treated.
Type 1 routes must be routes from internal gateway protocols with
external metrics that are directly comparable to OSPF metrics.
When OSPF selects a route, OSPF uses the type 1 route’s external
metric and adds the OSPF internal cost to the AS border router. Type
2 routes must be routes from external gateway protocols with metrics
that are not comparable to OSPF metrics. When OSPF selects a
route, OSPF ignores a type 2 route’s metric and uses only the OSPF
internal cost to the AS border router.
Defa u lt: 1
• exportlimitspecifies the rate at which ASE routes are imported
into the gatedrouting table for each exportinterval.
Defa u lt: 100 (ASE routes)
Ra n ge: 0 – 65535
• exportintervalspecifies the interval (in seconds) between ASE
exports into OSPF.
Defa u lt: 1 (second)
Ra n ge: 0 – 2147483647
82
Chapter 3
Configuring gated
Configuring the OSPF Protocol
Sa m p le OSP F Con figu r a tion
Figure 3-13 shows an example of two areas. Area 1 is a non-stub area,
while area 2 is configured as a stub area. Node B is an area border router
between the two areas.
Figu r e 3-13
OSP F Sa m p le Con figu r a tion
Area 1 (Non-Stub)
A
193.2.1.35
LAN 1 193.2.1.32
15.13.115.156
193.2.1.33
193.2.1.17
B
LAN 2 193.2.1.16
193.2.1.20
C
Area 2 (Stub)
A: In ter n a l Rou ter (Non -Stu b Ar ea )
Set up /etc/gated.confas follows:
Chapter 3
83
Configuring gated
Configuring the OSPF Protocol
# Router A Configuration (non-stub area)
OSPF yes {
area 0.0.0.1 {
interface 193.2.1.35 cost 5 {
priority 5 ;
enable ;
hellointerval 5 ;
routerdeadinterval 20 ;
retransmitinterval 10 ;
} ;
} ;
} ;
The configuration for the internal router A is for a multicast interface.
For an NBMA interface, you can set the configuration in
/etc/gated.conf as follows:
# Router A Configuration (non-stub area)
OSPF yes {
area 0.0.0.1 {
interface 193.2.1.35 nonbroadcast cost 5 {
routers {
193.2.1.33 eligible ;
} ;
priority 5 ;
enable ;
hellointerval 5 ;
routerdeadinterval 20 ;
retransmitinterval 10 ;
pollinterval 20 ;
} ;
} ;
} ;
NOTE
If you use IP multicasting in an area, every router and all the
intermediate network devices in that area must support IP multicasting.
B: Ar ea Bor d er Rou ter
Set up /etc/gated.confas follows:
OSPF yes {
defaults {
cost 5 ;
84
Chapter 3
Configuring gated
Configuring the OSPF Protocol
} ;
area 0.0.0.1 {
interface 193.2.1.33 cost 5 {
priority 15 ;
enable ;
hellointerval 5 ;
routerdeadinterval 20 ;
retransmitinterval 10 ;
} ;
} ;
area 0.0.0.2 {
interface 193.2.1.17 cost 5 {
priority 15 ;
enable ;
hellointerval 5 ;
routerdeadinterval 20 ;
retransmitinterval 10 ;
} ;
} ;
backbone {
interface 15.13.115.156 cost 5 {
enable ;
priority 10 ;
hellointerval 5 ;
routerdeadinterval 20 ;
retransmitinterval 10 ;
} ;
} ;
} ;
C: In ter n a l Rou ter (Stu b Ar ea )
Set up /etc/gated.confas follows:
OSPF yes {
area 0.0.0.2 {
stub cost 5 ;
interface 193.2.1.20 cost 5 {
priority 5 ;
enable ;
hellointerval 5 ;
routerdeadinterval 20 ;
retransmitinterval 10 ;
} ;
} ;
} ;
Chapter 3
85
Configuring gated
Configuring the OSPF Protocol
The routing table on node A contains routes to 193.2.1.32 and 193.2.1.16.
The routing table on node C in the stub area contains routes only to LAN
1 and a default router.
Accessin g th e OSP F MIB
HP’s gatedalso provides ospfagt, an OSPF Simple Management
Network Protocol (SNMP) subagent that supports the OSPF MIB
(Management Information Base) (see RFC 1253). The ospfagtsubagent
works with the HP SNMP Agent, snmpdm. If you use an SNMP manager
utility to manage your network, such as HP’s OpenView Network Node
Manager, you can also use HP’s OSPF SNMP subagent.
To start ospfagtautomatically during system bootup, set the
environment variable OSPFMIBto 1in the file
/etc/rc.config.d/netdaemons.
To manually start ospfagt, type the following command at the command
prompt:
/usr/sbin/ospfagt
gatedmust be running before ospfagtis started. Both gatedand
ospfagtmust be running to retrieve OSPF MIB objects.
To load the OSPF MIB, select Load/Unload SNMP:MIBS ...from the
Options menu of OpenView.
86
Chapter 3
Configuring gated
Configuring RDP
Con figu r in g RDP
You can use Router Discovery Protocol (RDP), a standard protocol, to
inform hosts of the presence of routers to which they can send packets.
You can also use RDP instead of host wiretapping routing protocols (for
example, RIP). It is used instead of, or in addition to, having statically
configured default routes in hosts.
RDP consists of two portions: the ser ver portion, which runs on routers,
and the clien t portion, which runs on hosts. gatedtreats these portions
as separate protocols; therefore, you can enable only one of them at a
time. These portions are described in detail in the subsequent sections.
For a description of the RDP configuration statements, type man 4
gated.confat the HP-UX prompt.
RDP Ser ver
The RDP server runs on routers, and announces the routers’ existence to
hosts periodically by multicasting or broadcasting a r ou ter
a d ver tisem en t. The advertisement is sent over an RDP server enabled
physical interface. Each router advertisement contains a list of all
addresses on a physical interface and their preference for being used as a
default router. You can configure the length of time (the lifetime) for
which addresses must remain on the list.
At first, router advertisements occur every few seconds, and then, they
start occurring few minutes. You can configure the minimum and
maximum intervals for router advertisements to occur. Also, a host can
send a r ou ter solicita tion , requesting an advertisement. The router
responds with a unicast router advertisement unless a multicast or
broadcast advertisement is due to occur.
On hosts that support IP multicasting, router advertisements are sent by
default to the all-hosts mulicast address 224.0.0.1. You can also
configuration RDP to use broadcasting to send router advertisements.
This is useful when a particular host does not support IP multicasting, or
when one or more hosts on an attached network do not support IP
multicasting. If router advertisements are sent to the all-hosts multicast
address, or if an interface is configured for the limited-broadcast address
255.255.255.255, the advertisements contain all the IP addresses
Chapter 3
87
Configuring gated
Configuring RDP
configured on the physical interface. If advertisements are sent to a net
or subnet broadcast, only that network’s or subnet’s address is included
in the advertisement.
An example of the routerdiscovery serverstatement is as follows:
routerdiscovery server yes {
interface lan1 lan2
maxadvinterval 5 ;
address 193.2.1.17 193.2.1.33 193.2.1.46
broadcast
preference 50 ;
} ;
In the example, the server is enabled on the physical interfaces lan1and
lan2, and the IP addresses 193.2.1.17, 193.2.1.33, and 193.2.1.46 are
included in all the router advertisements. Also, the addresses have a
preference of 50.
RDP Clien t
The RDP client runs on hosts, listening for router advertisements over
the all-hosts multicast address 224.0.0.1(if it supports IP
multicasting) or on the physical interface’s broadcast address (if the host
does not support multicasting). When a host starts up or is reconfigured,
it sends certain router solicitations requesting advertisements. When it
sends the solicitations, it sends them to the all-routers multicast address
224.0.0.2or to the interface’s broadcast address (if multicasting is not
supported).
When the RDP client receives a router advertisement, the host installs a
default route to each of the addresses listed in the advertisement. If the
advertisement has a preference of ineligible(that is, the addresses in
the advertisement are not eligible to be the default route for any hosts),
or if the addresses are not on an attached physical interface, the route is
marked as unusable but is still retained. If the preference is usable, then
that route is among the routes considered. The route with the highest
preference is used. If more than one route with the same preference is
received, the one with the lowest IP address is used. The default routes
are not exportable to other protocols.
If an RDP client receives a router advertisement with a zero lifetime
(that is, the addresses in the advertisement are no longer valid), the host
deletes all the routes with next-hop addresses learned from that router.
88
Chapter 3
Configuring gated
Configuring RDP
The host also deletes any routes learned from ICMP redirects pointing
to the invalid addresses. Also, if a router advertisement is not received
before the addresses listed by the host becomes invalid (that is, before its
lifetime expires), the routes learned from that router are deleted by the
host.
An example of the routerdiscovery clientstatement is as follows:
routerdiscovery client yes {
preference 50 ;
interface lan0
broadcast ;
} ;
In the example, the client is enabled on physical interface lan0, and the
default routes are given a preference of 50.
A simple example of an RDP server and two RDP clients is shown in
Figure 3-14.
Figu r e 3-14
RDP Ser ver a n d Clien ts Exa m p le
Router
RDP
Server
lan0
RDP
Client
RDP
Client
Host A
Host B
Chapter 3
89
Configuring gated
Customizing Routes
Cu stom izin g Rou tes
gatedmaintains the routing table in user space, and synchronizes this
table with the kernel routing table. This section describes statements for
setting up customized routes in the Static class of the gated
configuration file, /etc/gated.conf. You can use these statements to
specify default routers, static routes, passive interfaces, and routing
metrics for interfaces.
Sp ecifyin g a Defa u lt Rou ter
A static route provides a specific destination for network packets. The
static route is a network address or a host address through a router. This
route is installed in the kernel’s routing table. The following is an
example of a static route for the default route:
static {
default gateway 15.13.114.196 retain ;
} ;
The retainqualifier ensures that the entry is not deleted when gated
exists.
In sta llin g Sta tic Rou tes
The staticstatement specifies a router or an interface in the kernel
routing tables. The following is an example of a static route:
static {
193.2.1.32 mask 0xfffffff0 gateway 193.2.1.30
preference 8 retain ;
} ;
If you specify an exportstatement for the default route, the route is
passed on to other routers. If you specify only the staticstatement and
not an exportstatement, then the default route is not passed on as a
route to other routers. This is considered a passive default route, and is
used only by the host where this gatedis running. The retainclause
retains the route in the kernel even after gatedshuts down.
90
Chapter 3
Configuring gated
Customizing Routes
Settin g In ter fa ce Sta tes
gatedtimes out routes that pass through interfaces not receiving any
RIP, OSPF, or BGP packets. The passiveclause in the interface
statement of the Static class prevents gatedfrom changing the
preference of a route to the interface if routing information is not
received for the interface. HP recommends that you use the passive
clause for all interfaces.
Chapter 3
91
Configuring gated
Specifying Tracing Options
Sp ecifyin g Tr a cin g Op tion s
Trace options specify the desired level of tracing output from gated.
Tracing output provides useful system information for setting up a node
on the network. Use trace options to set up a node and to send a certain
type of tracing to a log file. You can specify tracing in the following ways:
•
•
•
In a protocol statement in the /etc/gated.confconfiguration file.
In the Trace class of the /etc/gated.confconfiguration file.
On the command line with the -toption when starting gated.
Trace information is appended to the trace file unless you specify
replace. Command-line options are useful for tracing events in gated
before the configuration file is read.
NOTE
In gated3.5.9, the two Trace class statements (tracefileand
traceoptions) are combined into one traceoptionsstatement.
Therefore, the tracefilestatement is eliminated. For details about the
new syntax, type man 4 gated.confat the HP-UX prompt.
Table 3-2 shows the gated.confglobal trace options related to protocols.
Ta ble 3-2
P r otocol-Rela ted Globa l Tr a ce Op tion s for ga ted Con figu r a tion
Files
Op tion
Effect
state
Traces the state machine transitions in the
protocols.
normal
policy
Traces the normal protocol events (abnormal
protocol events are always traced).
Traces the application of protocol and
user-specified policies to routes that are imported
and exported.
task
Traces the system interface and processing
associated with this protocol or peer.
92
Chapter 3
Configuring gated
Specifying Tracing Options
Ta ble 3-2
P r otocol-Rela ted Globa l Tr a ce Op tion s for ga ted Con figu r a tion
Files (Con tin u ed )
Op tion
Effect
timer
route
Traces the timer usage by this protocol or peer.
Traces all routing table changes for routes installed
by this protocol or peer.
general
all
A combination of normaland route.
Some of the options specified in Table 3-2 do not apply to all of the
protocols. For more information on options applicable for each protocol
and for the different trace options available within the configuration file,
type man 4 gated.confat the HP-UX prompt. See “Troubleshooting
gated” on page 101 for more information on tracing options.
Chapter 3
93
Configuring gated
Specifying Route Preference
gatedmaintains a routing table that consists of the route information
learned from OSPF and from other active routing protocols, such as RIP
or EGP. You can also configure static routes in the /etc/gated.conffile
with one or more staticclauses (see “Installing Static Routes” on
page 90 for more information).
The gatedrouting pool can therefore contain multiple routes to a single
destination. When multiple routes exist, the route chosen by gatedis
determined by the following (in order of precedence):
•
The preferencevalue associated with the route. The preference
value is a number in the range from 0 (most preferred) to 255 (least
preferred). Routes from different sources have different default
preference values. For example, OSPF routes within a given AS have
a preference value of 10. Table 3-3 shows the default preference
values of various types of routes.
•
•
If multiple routes use the same protocol and have the same
preference value, the route with the lowest metric or cost is chosen.
If metric or cost is the same, the router with the lowest IP address is
chosen.
Ta ble 3-3
Defa u lt P r efer en ce Va lu es of Rou tes
Rou te Typ e
P r efer en ce
/etc/gated.config Con figu r a tion
Interface
routes
0
Can be changed with interface
statement in Interface class.
OSPF inter-
and intra-areas
10
20
Cannot be changed.
Internal
default
Generated by BGP or EGP when
routing information is learned from
a peer.
ICMP Redirect
SNMP
30
50
Can be changed with redirect
statement in Protocol class.
Can be changed in SNMPstatement in
Protocol class.
94
Chapter 3
Configuring gated
Specifying Route Preference
Ta ble 3-3
Defa u lt P r efer en ce Va lu es of Rou tes (Con tin u ed )
Rou te Typ e
P r efer en ce
/etc/gated.config Con figu r a tion
Static routes
60
Can be changed in staticstatement
in Static class.
RIP
100
110
120
150
Can be changed with import
statement in Control class.
Point-to-point
interface
Can be changed with interface
statement in Interface class.
“Down”
interface
Can be changed with interface
statement in Interface class.
OSPF ASE
Can be changed in defaults
statement in OSPF protocol
definition and with import
statement in Control class.
BGP
EGP
170
200
254
Can be changed with import
statement in Control class.
Can be changed with import
statement in Control class.
Kernel
remnant
These are the static routes that are
retained in the kernel after gatedis
stopped. Preference value cannot be
configured.
You can define preference in the /etc/gated.conffile configuration file
in the following instances:
•
In the static route definition in the Static class. This preference
definition sets the preference for static routes. (See “Customizing
Routes” on page 90 for more information.) If this option is not set, the
preference values for static routes is 60.
•
In the interfacestatement options in the Interface class. This
preference definition sets the preference for routes to this interface.
If this option is not set, the preference value is 0. For more
information, type man 4 gated.confat the HP-UX prompt.
Chapter 3
95
Configuring gated
Specifying Route Preference
•
In a defaultsstatement in the OSPF protocol configuration. This
preference definition specifies the preference value of ASE routes
that are imported into OSPF. See “AS External Routes (AS Boundary
•
In an importstatement in the Control class of the /etc/gated.conf
file. This preference definition overrides any preference defined in
the defaultssection of the OSPF protocol configuration. See “AS
External Routes (AS Boundary Routers Only)” on page 80 and
“Importing and Exporting Routes” on page 97 for more information.
96
Chapter 3
Configuring gated
Importing and Exporting Routes
Im p or tin g a n d Exp or tin g Rou tes
You can propagate routes from one routing protocol to another using the
importand exportcontrol statements. Routes are imported into a
gatedforwarding table and exported out to the routing protocols.
For more information on importand exportstatements, type man 4
gated.confat the HP-UX prompt.
Th e im p or t Sta tem en t
importstatements restrict or control routes that are imported to the
gatedforwarding table. When routes are imported to the gated
forwarding table, you can export them to the routing protocols. You can
use importstatements to perform the following tasks:
•
Prevent routes from being imported into the gatedforwarding table
by using a restrictclause.
•
Assign a preference value to use when comparing a route with other
routes from other protocols. The route with the lowest preference is
installed in the gatedforwarding table. The individual protocols
configure the default preferences.
The format of the importstatement varies depending on the protocol
from which you are importing routes.
With OSPF, you can apply importstatements only to OSPF ASE routes.
All OSPF intra-area and inter-area routes are imported into the gated
forwarding table with an assigned preference of 10.
Th e exp or t Sta tem en t
exportstatements determine the routes that are exported from the
gatedforwarding table to the routing protocols. You can also restrict the
routes that are exported and assign metrics (values used for route
selection) to them. These metrics are applied only after the routes are
exported.
The format of the exportstatement varies depending on the original
protocol used to build the routes that you are exporting, and the protocol
to which you are exporting routes.
Chapter 3
97
Configuring gated
Importing and Exporting Routes
Exa m p les of im p or t a n d exp or t Sta tem en ts
The following importstatement imports a BGP route for network
195.1.1 to the gatedforwarding table with a preference of 15:
import proto bgp as 1 {
195.1.1 mask 0xffffff00 preference 15;
};
The following exportstatement exports to OSPF the ASE route that was
imported to the gatedforwarding table in the previous example. The
route was originally built by BGP and the destination of the route is
network 195.1.1.
export proto ospfase type 1 /* Export an ASE route to OSPF */
proto bgp as 1 {/*route came from BGP and AS 1*/
195.1.1 ; /* the route is to network 195.1.1 */
};
};
98
Chapter 3
Configuring gated
Starting gated
Sta r tin g ga ted
To start gated, complete the following steps:
1. Set the environment variable GATEDto 1in the file
/etc/rc.config.d/netconfto start gated automatically upon
system startup.
2. Reboot your system, or issue the following command to run the
gatedstartup script:
/sbin/init.d/gated start
You can also start gatedby running the command gdc start. The
following message appears to indicate that gatedhas started:
gated started, pid 29777
where 29777 is the process ID (pid)of the gatedprocess. You can specify
the command-line arguments for starting gatedwith the GATED_ARGS
environment variable in the file /etc/rc.config.d/netconf. Table 3-4
lists the commonly used command-line options for gated.
Ta ble 3-4
Com m a n d Lin e Op tion s for ga ted
F la g
Effect
-t
When used alone, -tcauses gatedto log all error messages
and route changes. It turns on the generaltrace option
automatically. When -tis followed by one or more trace
options, only those options are turned on. (See “Specifying
Tracing Options” on page 92 for more information.)
Multiple trace options are separated by commas. The -t
flag must immediately precede the other flags.
-C
-c
Specifies that the configuration file will be parsed for
Specifies that the configuration file will be parsed for
syntax errors. A dump file /var/tmp/gated_dumpis
created if there are no errors. Only the trace option
generalis logged. See “Specifying Tracing Options” on
page 92 for a detailed description of all the tracing options.
Chapter 3
99
Configuring gated
Starting gated
Ta ble 3-4
Com m a n d Lin e Op tion s for ga ted (Con tin u ed )
F la g
Effect
-n
Specifies that gatedwill not modify the kernel’s routing
tables.
For more information about the command-line options, type man 1M
gatedat the HP-UX prompt.
Ver ifyin g Th a t ga ted Is Ru n n in g
Issue the following command to determine if gatedis running:
/usr/bin/ps -ef | /usr/bin/grep gated
This command reports the process identification (PID), current time, and
the command invoked (gated). Following is an example output:
daemon 4484 1 0 Feb 18
?
0:00 gated
You can also check if gatedis running by issuing the following command:
gdc running
The following message appears to indicate that gatedis running:
gdc is running (pid 1312)
If gatedis not running, the following message appears:
gated is not running
100
Chapter 3
Configuring gated
Troubleshooting gated
•
•
•
•
•
•
•
“The gated Routing Table” on page 103
“The ripquery Tool” on page 103
“The ospf_monitor Tool” on page 103
“Common Problems” on page 104
Ch eck in g for Syn ta x Er r or s in th e Con figu r a tion File
After creating or modifying a gatedconfiguration file, you must start
gatedfrom the command line with the -Coption. This option parses the
the configuration file for syntax errors.
Tr a cin g ga ted Activity
gatedprints information about its activity in the form of tracing output.
This information includes routes that gatedreads, adds, and deletes
from the kernel routing table, as well as packets sent and received.
You can specify tracing either with the gated -tcommand-line option or
with the traceoptionsstatement in the /etc/gated.conffile. Using
any of the following combinations, you can determine where the tracing
output is printed and whether tracing is performed:
•
•
•
If you specify trace options and a trace file, tracing output is printed
to the log file.
If you specify trace options but do not specify a trace file, tracing
output is printed on the display where gatedwas started.
If you specify a trace file but do not specify any trace options, no
tracing takes place.
Chapter 3
101
Configuring gated
Troubleshooting gated
NOTE
In gated 3.5.9, the two statements in the Trace class (tracefileand
traceoptions) are combined into one traceoptionsstatement.
Therefore, the tracefilestatement is eliminated. For details about the
new syntax, type man 4 gated.confat the HP-UX prompt.
After tracing is started to a file, you can rotate the trace file. Receipt of a
SIGUSR1signal stops gatedfrom tracing and closes the trace file. The
trace file can then be moved out of the way. To send a SIGUSR1signal to
gated, issue one of the following commands:
/usr/bin/kill -SIGUSR1 pid
or
/usr/bin/kill -USR1 pid
where pid is the gated’s process ID, determined by invoking the
command ps -ef | grep gated.
A subsequent SIGUSR1signal starts tracing again to the same trace file.
If the trace options are changed before tracing is started again, the new
options are used.
NOTE
You cannot use the SIGUSR1signal if you did not previously specify
tracing to a file while starting gated.
Op er a tion a l User In ter fa ce for ga ted – gd c
gdcprovides a user-oriented interface for the operation of gated. It
provides the following functions:
•
•
•
•
Starting and stopping gated.
Delivery of signals to manipulate gated.
Maintenance and checking the gated configuration file for syntax.
Production and removal of state dumps and core dumps.
102
Chapter 3
Configuring gated
Troubleshooting gated
gdcdetermines the state of gatedand produces a reliable exit status
during errors, which is useful in shell scripts that manipulate gated. The
syslogdfacility is used to log all the commands and error messages
generated during gdcoperation. gateduses these log messages to
provide an audit trail of operations performed on the daemon.
For more information, type man 1M gatedat the HP-UX prompt.
Th e ga ted Rou tin g Ta ble
Sending gateda SIGINTsignal causes gatedto write information about
interface configurations, task information, and routing tables to the
/var/tmp/gated_dumpfile.
Th e r ip qu er y Tool
You can use the /usr/sbin/ripquerysupport tool to query gatedfor
RIP routing information. ripquerysends two types of commands: a POLL
command and a RIP requestcommand. gatedresponds to a POLL
command by listing all routes learned from RIP that are in its routing
table. This does not include the interface routes for the local network or
routes from other protocols that are announced through RIP. When
gatedreceives a RIP requestcommand on a interface, it announces
routes via RIP on that interface. This includes routes from other
protocols that are imported by gatedon the node.
You can use ripquerywith the -poption to query other non-gatedRIP
routers. With this option, ripqueryinitially sends POLLcommands and
then, if there is no response, sends RIP request commands. The default
query (POLLcommands) sent by ripquerymay not be supported by all
RIP routers. For more information, type man 1M ripqueryat the HP-UX
prompt.
Th e osp f_m on itor Tool
You can use the /usr/sbin/ospf_monitorsupport tool to query OSPF
routers for information on OSPF routing tables, interfaces, and
neighbors, as well as data on AS external databases, link-state
databases, error logs, and input/output statistics. Running the
ospf_monitorcommand displays a prompt that allows you to enter
interactive commands. For details on using this tool, type man 1M
ospf_monitorat the HP-UX prompt.
Chapter 3
103
Configuring gated
Troubleshooting gated
Com m on P r oblem s
This section discusses the common problems experienced during gated
operation.
P r oblem 1: ga ted d oes n ot a ct a s exp ected .
First, check the syslogdoutput for any syntax errors that may have
been flagged.
To detect incorrect configuration commands, use gatedtracing.
Following are two sample configurations, along with the trace files
generated by gated. The node used has three interfaces: lan0, lan1, and
lan2. In the configuration files, lan0, lan1, and lan3are specified. In
the first configuration shown, the strictintfsoption is specified for the
interfaces to ensure that gatedexits when the error is detected.
In ter fa ce Con figu r a tion With str ictin tfs Op tion Sp ecified The
following configuration references a non-existent interface. The options
strictintfsline in the interfacesstatement ensures that all the
configured interfaces exit before gatedstarts.
traceoptions "tt" general;
interfaces {
options strictintfs ;
interface lan0 lan1 lan3 passive ;
} ;
rip yes ;
The following is the tracing output that is produced when gatedis
started with this configuration:
trace_on: Tracing to "/tt" started
Tracing flags enabled: general
parse: conf.tt:4 Interface not found at ’lan3’
parse_parse: 2 parse errors
Exit gated[15941] version @(#)Revision: 1.0 based on Cornell G
ateD R3_5Beta_3
104
Chapter 3
Configuring gated
Troubleshooting gated
In ter fa ce Con figu r a tion With ou t str ictin tfs Op tion Sp ecified The
following configuration references a non-existent interface, but does not
include the strictintfsoption:
traceoptions "tt" general;
interfaces {
interface lan0 lan1 lan3 passive ;
} ;
rip yes ;
The following is the tracing output that is produced when gatedis
started with this configuration:
trace_on: Tracing to "/tt" started
Tracing flags enabled: general
inet_routerid_notify: Router ID: 15.13.119.134
You can also find the results of this same command in the gated_dump
file. In the following segment of a gated_dumpfile, the interface is listed
as passive in the interface policy statement toward the end of this
example:
Interfaces:
lo0
Index 1
Change: <>
State: <Loopback>
Refcount: 2
Up-down transitions: 0
127.0.0.1
Metric: 0
Refcount: 4
Change: <>
MTU: 4072
Preference: 0 Down: 120
State: <Up Loopback Multicast>
Subnet Mask: 255.255.255.255
proto: RIP
State: <NoIn NoOut>
lan0
Index 2 Address 802.2 8:0:9:1b:da:1f
Change: <>
State: <>
Refcount: 2
Up-down transitions: 0
15.13.119.134
Metric: 0
Refcount: 6
Change: <>
MTU: 1436
Preference: 0 Down: 120
State: <Up Broadcast Multicast
NoAge>
Broadcast Address: 15.13.119.255
Subnet Number: 15.13.112
Subnet
Mask: 255.255.248
Chapter 3
105
Configuring gated
Troubleshooting gated
lan2
Index 3 Address 802.2 8:0:9:3d:2c:b1
Change: <>
State: <>
Refcount: 2
Up-down transitions: 0
198.1.1.17
Metric: 0
Refcount: 4
Change: <>
MTU: 1436
Preference: 0 Down: 120
State: <Up Broadcast Multicast
>
Broadcast Address: 198.1.1.255
Subnet Number: 198.1.1
Subnet Mask: 2
55.255.255
lan1
Index 4 Address 802.2 8:0:9:3d:3c:69
Change: <>
State: <>
Refcount: 2
Up-down transitions: 0
198.2.1.40
Metric: 0
Refcount: 4
Change: <>
MTU: 1436
Preference: 0 Down: 120
State: <Up Broadcast Multicast
NoAge>
Broadcast Address: 198.2.1.255
Subnet Number: 198.2.1
Subnet Mask: 2
55.255.255
Interface policy:
Interface lan0 lan1 lan3 passive
The state recorded in lan2does not contain the NoAgeflag, because the
interface was not set to passive in the interface policy statement.
A common mistake is to expect gatedto always send out RIP packets
when you specify rip yesin a configuration file. gatedwill be an active
RIP participant only if the host is a router (that is, when the host has
more than one network interface).
P r oblem 2: ga ted d eletes r ou tes fr om th e r ou tin g ta ble.
gatedmaintains a complete routing table in user space, and
synchronizes this table with the kernel routing table. When gatedstarts,
it reads the entries in the kernel routing table. However, if gateddoes
not get confirmation from its routing protocols (RIP, OSPF, and so on)
about a route, it deletes the route from its tables and from the kernel
routing table.
106
Chapter 3
Configuring gated
Troubleshooting gated
Normally, gated deletes the route configured in the
/etc/rc.config.d/netconffile. To solve this problem, configure a
static default route as described in the section “Installing Static Routes”
on page 90.
Another common scenario occurs in networks where all the gateways do
not implement the gatedrouting protocols. In this situation, routes that
do not use gatedgateways are not confirmed by gated, and gated
deletes them unless a static statement is included in /etc/gated.conf:
static {
13.0.0.0 mask 0xff000000 gateway 15.14.14.14 ;
};
The staticentry in this example ensures that the local system includes
a route to network 13.0.0.0 even though the gateway to that network
(15.14.14.14) is not running any of the gatedprotocols.
You can include the restrictclauses in the exportstatements to
restrict these extra routes from being advertised.
P r oblem 3: ga ted a d d s r ou tes th a t a p p ea r to be in cor r ect.
If gated adds routes that appear to be incorrect, track the original source
of the route by completing the following steps:
1. Start by looking at the routing table maintained by gated.
2. Send gateda SIGINTsignal, and look at the information output in
the /var/tmp/gated_dumpfile.
3. Look for the entry of the route in question. The entry identifies the
protocol over which this route was heard and the first-hop router.
The first-hop router is likely to be the immediate source of the
information.
Perform one of the following actions:
•
If the route was learned over RIP, use /usr/sbin/ripqueryto query
the first-hop router for the route. That router may claim to have
heard the route from another router.
•
If the first-hop router is another host running gated, have that host’s
gateddump its routing table to find out where it learned about the
route.
Chapter 3
107
Configuring gated
Troubleshooting gated
You may have to repeat this process several times to track down the
original source of the route. If you expect the route to go through a
different router, turn on gatedtracing. The tracing tells you which
routes.
P r oblem 4: ga ted d oes n ot a d d r ou tes th a t you th in k it m u st.
Tracking down this problem is similar to the previous problem (“Problem
3: gated adds routes that appear to be incorrect.” on page 107). You
expect one or more routers to advertise the route. Turn on gatedtracing
to verify that gatedis receiving packets of the type of routing protocol
you expect. If these packets do not contain a route you expect to be there,
trace packets on the router you expect to advertise the route.
108
Chapter 3
A
all hosts group, 19
D
area border router, 61
configuration example, 75
area statement
in /etc/gated.conf file, 65
defaultmetric statement
defaults statement
designated router
areas, OSPF, 63
example configuration, 65
AS, 23
See autonomous system
Assigned Numbers Authority, 63
authentication in OSPF, 77
authkey statement
in /etc/gated.conf file, 69, 78
authtype statement
in /etc/gated.conf file, 77
autonomous system
areas, 61
boundary routers, 61
external routes, 81
obtaining a number for, 24
obtaining a number from IANA, 63
routing levels, 63
E
/etc/gated.conf file, 45
area statement, 65
broadcast clause, 51, 52
checking syntax, 99
B
backbone statement
in /etc/gated.conf, 76
configuration classes, 45
backbone, OSPF, 62, 76
configuration example, 76
BGP routing protocol, 26
Border Gateway Protocol
See BGP routing protocol
broadcast clause
defaults statement, 80, 81
examples, 48
export statement, 80, 90, 97
exportlimit value, 82
in /etc/gated.conf file, 51, 52
broadcast network interface, 67, 68
C
cache_lifetime command
in mrouted, 34
configuration
gated, 45
mrouted, 31
metricout clause, 52
nobroadcast clause, 51, 53
nonbroadcast clause, 70, 73
noripin clause, 52, 59
noripout clause, 52, 57, 58
ospf statement, 64
OSPF protocol, 60
conv_config gated conversion tool, 49
converting gated
from 3.0 to 3.5.9, 49
to 3.5, 49
passive clause, 57
pollinterval statement, 71, 73
preference clause, 51, 81, 94
cost
in OSPF, 79
cost clause
109
In d ex
priority statement, 68
query authentication clause, 52
retain clause, 90
retransmitinterval statement, 68, 72
rip statement, 50
ripin clause, 52
ripout clause, 52
routerdeadinterval statement, 69, 73
routers statement, 71
secondary authentication clause, 53
sourcegateways clause, 51, 53, 58
static statement, 90
stub statement, 74
stubhosts statement, 73, 80
tag value, 82
traceoptions statement, 53
transmitdelay statement, 68
trustedgateways clause, 53, 59
type value, 82
H
hellointerval statement
hopcount
version clause, 52
/etc/mrouted.conf file, 31
name command, 31
pruning command, 31
/etc/rc.config.d/netconf file, 48
EGP routing protocol, 26
encapsulation, 18
equal cost multipath
See host ID field
in OSPF protocol, 24
Ethernet multicast address, 20
export statement
I
exporting RIP routes, 58
exportinterval value
IANA, 24, 63
ICMP protocol, 19
IFF_MULTICAST flag, 31
in /etc/gated.conf file, 82
exportlimit value
in /etc/gated.conf file, 82
External Gateway Protocol
See EGP protocol
interface clause
G
gated, 43
advantages, 22
checking 3.0 compatibility with 3.5, 46
common problems, 104
configuring, 45
Internet Control Message Protocol, 19
See ICMP protocol
Internet Group Management Protocol
See IGMP protocol
intra-area routing, 63
IP multicast addressing, 19
IP multicast datagram, 18
converting configuration file to 3.5, 49
customizing routes, 90
default router, 90
holddown mode, 50
110
In d ex
IP type of service routing feature, 24
nobroadcast clause
nocheckzero statement
in /etc/gated.conf file, 51
nonbroadcast clause
K
kernel routing table, 22, 100
L
link state advertisement, 62
M
configuration example, 71
noripin clause
management information base
See MIB
metricin clause
in /etc/gated.conf file, 52
metricout clause
in /etc/gated.conf file, 52
MIB, 24
mixing protocols, 25
mrouted
area border routers, 61
configuration command
phyint command, 31
tunnel command, 32
logging, 36
routing tables, 38
starting, 36
support tools, 41
verifying operation, 37
mrouted.cache file, 38
multicast clause
in /etc/gated.conf file, 52
multicast group address, 19
multicast network interface, 67, 68
example configuration, 70
multicast routing cache table, 38
multicast routing table, 38
multicasting, 18
designated router, 62, 64, 68, 71
enabling, 64
equal cost multipath, 24
networks, 66
N
name command
router interfaces, 63
ospf statement
in /etc/gated.conf file, 64
ospf_monitor command, 103
in mrouted, 35
NBMA, 67
network interface, 67, 70
neighbor routers, 61
netconf file, 99
netid
See network ID field
network definition for OSPF, 66
network ID field
in IP address, 19
networks statement
P
passive clause
in /etc/gated.conf file, 57
111
In d ex
password authentication
in OSPF, 78
router advertisement, 87
See RDP protocol
configuration example, 78
phyint command
routers statement
in mrouted, 32
point-to-point network interface, 68, 72
configuration example, 74
pollinterval statement
in /etc/gated.conf file, 71, 73
preference clause
between areas, 63
in /etc/gated.conf file, 51, 81, 94
priority statement
in /etc/gated.conf file, 68
pruned broadcast delivery tree, 18
pruning command
in mrouted, 35
protocols, 23
within the same area, 63
See RIP routing protocol
routing protocols
EGP protocol, 26
Q
query authentication clause
in /etc/gated.conf file, 52
OSPF protocol, 24, 60, 61, 62, 63, 64, 66, 67
R
RDP protocol, 26, 87
client, 88
server, 87
retain clause
in /etc/gated.conf file, 90
retransmitinterval statement
in /etc/gated.conf file, 68, 72
RFC 1058, 24, 51, 52
RFC 1060, 19
in /etc/gated.conf file, 51, 53, 58
RFC 1163, 26
RFC 1247, 24
RFC 1253, 86
RFC 1267, 26
RFC 1388, 24, 52
RIP routing protocol, 24, 50
configuration
configuration example, 75
example, 54
options, 53
sample, 55
exporting routes, 58
rip statement
in /etc/gated.conf file, 50
ripin clause
T
in /etc/gated.conf file, 52
ripout clause
in /etc/gated.conf file, 52
ripquery tool, 103
route manpage, 23
tag value
in /etc/gated.conf file, 82
time-to-live
See TTL
112
In d ex
TOS
routing feature, 24
traceoptions statement
in /etc/gated.conf file, 53
tracing
gated, 92, 99, 101
transmitdelay statement
in /etc/gated.conf file, 68
TRPB, 18
See TRPB
trustedgateways clause
in /etc/gated.conf file, 53, 59
TTL
in mrouted, 33
tunnel command
in mrouted, 32
tunnelling
in mrouted, 18
type of service
See TOS
type value
in /etc/gated.conf file, 82
U
/usr/tmp/mrouted.dump file, 38
V
/var/adm/syslog/syslog.log file, 36
/var/tmp/mrouted.cache file, 38
/var/tmp/mrouted.dump file, 38
version clause
in /etc/gated.conf file, 52
virtual interface table, 38
virtual links in OSPF, 77
113
|