*** UNIX MANUAL PAGE BROWSER ***

gated.conf(4) Kernel Interfaces Manual gated.conf(4) NAME gated.conf - Gate daemon configuration file (general information) DESCRIPTION The gated.conf file contains configuration information that is read by the gated daemon at initialization time. This file contains statements that control tracing options, select routing protocols, manage routing information, and manage independent system routing. The gated.conf file consists of a sequence of statements terminated by a semi-colon (;). Statements are composed of tokens separated by any combination of blanks, tabs, and newlines. This structure simplifies identification of the parts of the configuration associated with each other and with specific protocols. Comments can be specified by either of the following: A number sign (#) The C-style /* and */ characters. Syntax description conventions Keywords and special characters that the parser expects are displayed using the HTML strong style. Parameters are specified in the HTML variable definition style. Parameters shown in brackets ([]) show op- tional keywords and parameters. The vertical bar (|) indicates a choice of optional parameters. Parentheses (()) group keywords and pa- rameters, when necessary. For example: [backbone | (area area)] In this example, the brackets indicate that either parameter is op- tional. The keywords are backbone and area. The vertical bar indi- cates that either backbone or area area can be specified. Because area is in the variable definition0 style, it is a parameter that needs to be provided. Statement Grouping The configuration statements and the order in which they appear divide the gated.conf file into options statements, interface statements, def- inition statements, protocol statements, static statements, control statements, and aggregate statements. Entering a statement out of or- der causes an error when parsing the configuration file. Two other types of statements do not fit in these categories: %direc- tive statements and %trace statements. These statements provide in- structions to the parser and control tracing from the configuration file. They do not relate to the configuration of any protocol and may occur anywhere in the gated.conf file. Configuration Statement Summary The following table lists each gated.conf configuration statement by name, identifies the statement type, and gives a synopsis of the state- ment's function: tab(@); lfHB lfHB lfHB lfCW l l . _ Command@Type@Synopsis _ %directory@directive@Sets the directory for include files. %in- clude@directive@Includes a file into gated.conf. traceop- tions@trace@Specifies which events are traced. options@definition@De- fines gated options. interfaces@definition@Defines gated interfaces. autonomoussystem@definition@Defines the AS number. routerid@defini- tion@Defines the originating router (BGP, OSPF). martians@defini- tion@Defines invalid destination addresses. rip@protocol@Enables the RIP protocol. hello@protocol@Enables the HELLO protocol. isis@proto- col@Enables the ISIS protocol. kernel@protocol@Configures kernel in- terface options. ospf@protocol@Enables the OSPF protocol. egp@proto- col@Enables the EGP protocol. bgp@protocol@Enables the BGP protocol. redirect@protocol@Configures the processing of ICMP redirects. icmp@protocol@Configures the processing of general ICMP packets. snmp@protocol@Enables reporting to SNMP. static@static@Defines static routes. import@control@Defines which routes to import. export@con- trol@Defines which routes to export. aggregate@control@Defines which routes to aggregate. generate@control@Defines which routes to gener- ate. _ Preferences and Routing The gated.conf files can define routes from one protocol or peer to an- other, assigning each route a value called a preference. The preference value determines the order of routes to the same desti- nation in a single routing database. The active route is chosen by the lowest preference value. Some protocols implement a second preference (preference2), sometimes referred to as a tie breaker. Use the following guidelines when setting preferences: It can be set in several different configuration statements in gated.conf, although the last or most specific value set for a route is the one used. (See gated_intro(7).) It can be specify one network interface over another, one protocol over another, or one remote gateway over another. It can- not be used to control the selection of routes within an interior gate- way protocol (IGP). That function is accomplished automatically by the protocol based on metric. It can be used to select routes from the same exterior gateway protocol (EGP) learned from different peers or autonomous systems. Selecting a route The gated daemon uses the following criteria to select a route: The route with the best (numerically smallest) preference is preferred. If the two routes have the same preference, the route with the best (nu- merically smallest) preference2 (also known as a tie breaker) is pre- ferred. A route learned from an IGP is preferred to a route learned from an EGP. The least preferred is a route learned indirectly by an IGP from an EGP. If autonomous system (AS) path information is avail- able it is used to help determine the most preferred route as follows: A route with an AS path is preferred over one without and AS path. If the AS paths and origins are identical, the route with the lower metric is preferred. A route with an AS path origin of IGP is preferred over a route with an AS path origin of EGP. The least preferred is an AS path with an unknown origin. A route with a shorter AS path is pre- ferred. If both routes are from the same protocol and AS, the one with the lowest metric is preferred. The route with the lowest numeric next-hop address is used. Assigning preferences A default preference is assigned to each source from which gated re- ceives routes. Preference values range from 0 to 255, with the lowest number indicating the most preferred route. The following table lists each type of route, the statement (or clause within statements) that sets preference for the route, and the default preference for each type of route. Note that a statement that is narrow in scope has a higher precedence given to its preference value, but affects a smaller set of routes. tab(@); lfHB lfHB lfHB l l l. _ Preference of@Defined by Statement@Default _ Direct connected net- works@interface@0 OSPF routes@ospf@10 IS-IS level 1 routes@isis level 1@15 IS-IS level 2 routes@isis level 2@18 Internally generated de- fault@gendefault@20 Redirects@redirect@30 Routes learned via route socket@kernel@40 Static routes from config@static@60 ANS SPF (SLSP) routes@slsp@70 HELLO routes@hello@90 RIP routes@rip@100 Point-to-point interface@@110 Routes to interfaces that are down@interfaces@120 Aggre- gate/generate routes@aggregate/generate@130 OSPF AS external routes@ospf@150 BGP routes@bgp@170 EGP@egp@200 _ Sample Preference Specifications In the following statements, the preference applicable to routes learned via RIP from gateway 138.66.12.1 is 75. The last preference applicable to routes learned via RIP from gateway 138.66.12.1 is de- fined in the accept statement. The preference applicable to other RIP routes is found in the rip statement. The preference set on the inter- face statement applies only to the route to that interface. interfaces { interface 138.66.12.2 preference 10 ; } ; rip yes { preference 90 ; } ; import proto rip gateway 138.66.12.1 preference 75 ; Trace Options Statement Trace options statements control tracing options. The gated daemon's tracing options may be configured at many levels. Tracing options in- clude the file specifications, control options, and global and protocol specific tracing options. Unless overridden, tracing options from the next higher level are inherited by lower levels. For example, Border Gateway Protocol (BGP) peer tracing options are inherited from BGP group tracing options, which are inherited from global BGP tracing op- tions, which are inherited from global gated tracing options. At each level, tracing specifications override the inherited options. Syntax traceoptions [trace_file [replace] [size size[k|m] files files]] [control_options] trace_options [except trace_options] ; traceoptions none ; Specifies the file to receive tracing information. If this file name does not begin with a slash (/), the directory in which gated was started is prepended to the name. Replaces an existing trace file. The default is to append to an existing file. Limits the maximum size of the trace file to the specified size (minimum 10 kilobytes). When the trace file reaches the specified size, it is renamed to file.0, then file.1, file.2, up to the maximum number of files (minimum speci- fication is 2). Specifies options that control the appearance of trac- ing. The only valid value is nostamp, which specifies that a time stamp should not be prepended to all trace lines. Enables a broad class of tracing and then disables more specific options. Specifies that all tracing should be turned off for this protocol or peer. Global tracing options There are two types of global options: those with global significance and those with protocol significance. Global significance The following trace flags have global significance: Traces the lexical analyzer and parser. Used mainly by gated developers for debugging. Traces the allocation of and freeing of policy blocks. Used mainly by the gated developers for debugging. Traces symbols read from the ker- nel at startup. The principal means to specify this level of tracing is by the -t option on the command line, because the symbols are read from the kernel before parsing the configuration file. Traces the reading of the kernel interface list. It is useful to specify this with the -t option on the command line because the first interface scan is done before reading the configuration file. Protocol significance The following options flags have potential significance to protocols: Turns on all of the options flags. A shorthand notation for specifying both normal and route. Traces state machine transitions in the proto- cols. Traces normal protocols occurrences. Abnormal protocol occur- rences are always traced. Traces application of protocol and user- specified policy to routes being imported and exported. Traces system interface and processing associated with this protocol or peer. Traces timer usage by this protocol or peer. Traces routing table changes for routes installed by this protocol or peer. Note Not all of these options apply to all of the protocols. In some cases, their use does not make sense (for instance, RIP does not have a state machine) and in some instances the requested tracing has not been im- plemented (such as RIP support of the policy option). It is not possible to specify packet tracing from the command line be- cause a global option for packet tracing would potentially create too much output. When protocols inherit their tracing options from the global tracing options, tracing levels that do not make sense (such as parse, adv, and packet tracing options) are masked out. Global tracing statements have an immediate effect, especially parsing options that affect the parsing of the configuration file. Tracing values inherited by protocols specified in the configuration file are initially inherited from the global options in effect as they are parsed, unless they are overridden by more specific options. After the configuration file is read, tracing options that were not ex- plicitly specified are inherited from the global options in effect at the end of the configuration file. Packet tracing The tracing of packets is flexible. Every protocol has one or more op- tions for tracing packets. All protocols allow the packets keyword to be used for tracing all packets sent and received by the protocol. Most protocols have other options for limiting tracing to a useful sub- set of packet types. These tracing options can be further controlled with the following modifiers: Specifies a more verbose format to pro- vide more information about the contents of the packet. The detail op- tion must be specified before send or recv. By default, packets are traced in a terse form of one or two lines. Limit the tracing to pack- ets sent received. If neither send nor recv option is specified, both sent and received packets are traced. Limit the tracing to packets re- ceived. If neither send nor recv option is specified, both sent and received packets are traced. Note If a protocol allows for several different types of packet tracing, modifiers can be applied to each individual type. Be aware, however, that within one tracing specification the trace flags are summed up, so specifying detail packets turns on full tracing for all packets. Directive Statements Directive statements provide direction to the gated configuration lan- guage parser about included files and the directories in which these files reside. Directive statements are immediately acted upon by the parser. Other statements terminate with a semi-colon (;), but direc- tive statements terminate with a newline. The two directive statements are as follows: Defines the directory in which the include files are stored. When it is used, gated searches the directory identified by pathname for any included files that do not have a fully qualified file name (do not begin with "/"). This statement does not change the cur- rent directory; it only specifies the prefix applied to included file names. Identifies an include file. The contents of the file is in- cluded in the gated.conf file at the point where the %include directive is located. If the file name is not fully qualified (does not begin with "/"), it is considered to be relative to the directory defined in the %directory directive. The %include directive statement causes the specified file to be parsed completely before resuming with this file. Nesting up to ten levels is supported. The maximum nesting level can be increased by changing the definition of FI_MAX in the parse.h file. In a complex environment, segmenting a large configuration into smaller more easily understood segments might be helpful, but one of the advan- tages of gated is that it combines the configuration of several differ- ent routing protocols into a single file. Segmenting a small file un- necessarily complicates routing configurations. Options Statements The options statement allows specification of some global options. If used, options must appear before any other type of configuration state- ment in the gated.conf file. Syntax options [nosend] [noresolv] [gendefault [preference preference] [gateway gateway]] [syslog [upto] log_level] ark time] ; The options list can contain one or more of the following options: When gendefault is enabled and a BGP or EGP neighbor is up, a default route with the special protocol default is created. This can be disabled per BGP/EGP group with the nogendefault option. By default, this route has a preference of 20. This route is normally not installed in the kernel forwarding table; it is only present so it can be announced to other protocols. If a gateway is specified, the default route is installed in the kernel forwarding table with a next hop of the listed gateway. Note that the use of the more general option is preferred to the use of the gendefault option. The gendefault option may be re- moved in the future. See the section on Route Aggregation in gated.control(4) for more information on the generate statement. Do not send any packets. This option makes it possible to run gated on a live network to test protocol interactions without actually participating in the routing protocols. The packet traces in the gated log can be examined to verify that gated is functioning properly. This is useful for RIP and HELLO and pos- sibly the SMUX SNMP interface. This option does not apply to BGP and is not useful with EGP and OSPF. By default, gated tries to resolve symbolic names into IP addresses by using the gethostbyname() and getnetbyname() library calls. These calls usually use the Domain Name System (DNS) instead of the host's local host and network tables. If there is insufficient routing information to send DNS queries, gated deadlocks during startup. This option can be used to prevent these calls; symbolic names result in configuration file errors. Controls the amount of data gated logs via syslog on systems where setlogmask() is sup- ported. The available logging levels and other terminology are as defined in setlogmask(3). The default is equivalent to sys- log upto info. Specifying this option causes gated to output a message to the trace log at the specified interval. This can be used to determine if gated is still running. Interfaces Statement An interface is the connection between a router and one of its attached networks. A physical interface can be specified by interface name, by IP address, or by domain name (unless the network is an unnumbered point-to-point network). Multiple levels of reference in the configu- ration language allow identification of interfaces using a wild card, interface type name, or delete word address. Be careful with the use of interface names because future versions might allow more than one address per interface. The interface_list is a list of one or more in- terface names including wildcard names (names without a number) and names that may specify more than one interface or address, or the token all for all interfaces. Syntax interfaces { options [strictinterfaces] [scaninterval time] ; interface interface_list [preference preference] [down preference preference] [passive] [simplex] [reject] [blackhole] ; define address [broadcast address] | [pointtopoint address] [netmask mask] ulticast] ; } ; Allows configuration of the following global options re- lated to interfaces: Indicates that it is a fatal error to reference an interface in the configuration file that is not present when gated is started and not listed in a define statement. Without this option, a warning message is issued but gated continues. Specifies how often gated scans the kernel interface list for changes. The default is every 15 seconds on most systems, and 60 seconds on systems that pass interface status changes through the routing socket (BSD 4.4). Note that gated also scans the interface list on receipt of a SIGUSR2. Sets interface options on the specified interfaces. An interface list is all or a list of interface names (see the Interface lists section), do- main names, or numeric addresses. Options available on this statement are: Sets the preference for routes to this interface when it is up and appears to be functioning properly. The default preference is 0. Sets the preference for routes to this interface when gated does not believe it to be functioning properly, but the kernel does not indicate it is down. The default value is 120. Prevents gated from changing the preference of the route to this interface if it is not believed to be functioning properly due to lack of received routing information. The gated daemon only performs this check if the interface is actively par- ticipating in a routing protocol. Defines an interface as unable to hear its own broadcast packets. Some systems define an interface as simplex with the IFF_SIMPLEX flag; others require it to be specified in the configuration file. On simplex interfaces, a sender's own packets are assumed to have been looped back in software and are not used as an indication that the interface is functioning properly. Specifies that the address of the interface matching these criteria is used as the lo- cal address when installing reject routes in the kernel. Use this only with systems based on BSD 4.3 Tahoe or earlier that have installed a reject/blackhole pseudointerface. Specifies that the address of the interface matching these criteria is used as the local address when in- stalling reject routes in the kernel. Use this only with systems based on BSD 4.3 Tahoe or earlier that have installed a reject/blackhole pseudo interface. Defines interfaces that might not be present when gated is started so they may be referenced in the configuration file when strictinterfaces is defined. The following are valid define key- words: Defines the interface as broadcast capable (for example, Ether- net or Token Ring) and specifies the broadcast address. Defines the interface as a point-to-point interface (for example, SLIP or PPP) and specifies the address on the local side. The first address on the de- fine statement references the address of the host on the remote end of the interface, the address specified after this pointopoint keyword de- fines the address on the local side of the interface. An interface that is not defined as broadcast or point-to-point is assumed to be nonbroadcast multiaccess (NBMA), such as an X.25 network. Specifies the subnet mask to be used on this in- terface. This is ignored on point-to-point interfaces. Speci- fies that the interface is multicast capable. Interface lists An interface list is a list of references to interfaces or groups of interfaces. The following four methods, from most general to most spe- cific, are available for referring to interfaces: Refers to all avail- able interfaces. Refers to all the interfaces of the same type. DIGI- TAL UNIX interfaces consist of the device driver name and a unit num- ber; for example, le0. References to the name contain only alphabetic characters and match any interfaces that have the same alphabetic part. For example, le refers to all Lance Ethernet interfaces, but le does not match lel0. Refers to a specific interface, usually one physical interface. These are specified as an alphabetic part followed by a numeric part. This will match one specific interface. But be aware that on many systems, there can be more than one protocol (for example, IP) address on a given physical interface. For example, ef1 matches an interface named ef1, but not an interface named ef10. Matches one specific interface. The reference can be by protocol address (for example, 10.0.0.51) or by symbolic host name (for example, nic.ddn.mil). Note that a symbolic host name reference is only valid when it resolves to only one address. Use of symbolic host names is not recommended. If many interface lists are present in the gated.conf file with more than one parameter, these parameters are collected at run time to cre- ate the specific parameter list for a given interface. If the same pa- rameter is specified on more than one list, the parameters with the most specific interface are used. For example, the following interface list is for a system with three interfaces, le0, le1, and du0: rip yes { interface all noripin noripout ; interface le ripin ; interface le1 ripout ; } ; In this example, RIP packets are accepted from interfaces le0 and le1, but not from du0. RIP packets are sent only on interface le1. IP Interface addresses and routes The BSD 4.3 and later networking implementations allow the following four types of interfaces. Some implementations allow multiple protocol addresses per physical interface, but these are mostly based on BSD 4.3 Reno or later. This interface must have the address of 127.0.0.1. Packets sent to this interface are sent back to the originator. This interface is also used as an interface for implementing other features, such as reject and blackhole routes. Although a netmask is reported on this interface, it is ignored. It is useful to assign an additional address to this interface that is the same as the OSPF or BGP router ID; this allows routing to a system based on the router ID that will work if some interfaces are down. This is a multiaccess interface ca- pable of a physical level broadcast, such as Ethernet, Token Ring, and FDDI. This interface has an associated subnet mask and broadcast ad- dress. The interface route to a broadcast network is a route to the complete subnet. This is a tunnel to another host, usually on some sort of serial link. This interface has a local address and a remote address. Although it may be possible to specify multiple addresses for a point-to-point interface, there is no useful reason for doing so. The remote address must be unique among all the interface ad- dresses on a given router. The local address may be shared among many point-to-point interfaces and up to one non-point-to- point interface. This is technically a form of the router ID method for addressless links. This technique conserves subnets, because none are required when using this technique. If a subnet mask is specified on a point-to-point interface, it is only used by RIP version 1 and HELLO to determine which sub- nets may be propagated to the router on the other side of this interface. This type of interface is multiaccess, but not capa- ble of broadcast; for example frame relay and X.25. This type of interface has a local address and a subnet mask. The gated daemon ensures that there is a route available to each IP in- terface that is configured and up. Normally this this done by the if- config command that configures the interface; gated does it to ensure consistency. For point-to-point interfaces, gated installs some special routes. If the local address on one or more point-to-point interfaces is not shared with a non-point-to-point interface, gated installs a route to the local address pointing at the loopback interface with a preference of 110. This ensures that packets originating on this host destined for this local address are handled locally. OSPF prefers to route packets for the local interface across the point- to-point link where they will be returned by the router on the remote end. This is used to verify operation of the link. Because OSPF in- stalls routes with a preference of 10, these routes override the route installed with a preference of 110. If the local address of one or more point-to-point interfaces is shared with a non-point-to-point interface, gated installs a route to the lo- cal with a preference of 0 that is not installed in the forwarding ta- ble. This prevents protocols like OSPF from routing packets to this address across a serial interface when this system could be functioning as a host. When the status of an interface changes, gated notifies all the proto- cols, which take the appropriate action. The gated daemon assumes that interfaces that are not marked UP do not exist. The gated daemon ignores any interfaces that have invalid data for the local, remote, or broadcast addresses or the subnet mask. Invalid data includes zeros in any field. The gated daemon also ignores any point- to-point interface that has the same local and remote addresses; it as- sumes it is in some sort of loopback test mode. Definition Statements Definition statements are general configuration statements that relate to all of gated, or at least to more than one protocol. The three def- inition statements are autonomoussystem, routerid, and martians. If used, autonomoussystem, routerid, and martians must appear before any other type of configuration statement in gated.conf file. Autonomous System configuration autonomoussystem autonomous_system [loops number] ; Sets the autonomous system number of this router to be autonomous_sys- tem. This option is required if BGP or EGP are in use. The AS number is assigned by the Network Information Center (NIC). The loops parameter is only for protocols supporting AS paths, such as BGP. It controls the number of times this autonomous system may appear in an AS path and defaults to 1 (one). Router ID configuration routerid host ; Sets the router identifier for use by the BGP and OSPF protocols. The default is the address of the first interface encountered by gated. The address of a non-point-to-point interface is preferred over the lo- cal address of a point-to-point interface and an address on a loopback interface that is not the loopback address (127.0.0.1) is most pre- ferred. Martian configuration Sometimes a misconfigured system sends out invalid destination ad- dresses. These invalid addresses, called martians, are rejected by the routing software. A martian configuration defines a list of martian addresses from which all routing information is ignored. A martian configuration is structured as follows: martians { host host [allow] ; network [allow] ; network mask mask [allow] ; network masklen number [allow] ; default [allow] ; } ; Adds martian addresses to the list of martian addresses. You can spec- ify the allow parameter to explicitly allow a subset of a range that was disallowed. (See the section on Route Filtering in gated.con- trol(4) for more information on specifying ranges.) Sample Definition Statements The following is an example of definition statements for a system: op- tions gendefault ; autonomoussystem 249 ; interface 128.66.12.2 passive ; martians { 0.0.0.26 }; A description of each statement in this example follows: The options statement tells the system to generate a default route when it peers with an EGP or BGP neighbor. The autonomoussystem statement tells gated to use AS number 249 for EGP and BGP. The interface statement tells gated not to mark interface 128.66.12.2 as down even if it sees no traffic. The martians statement prevents routes to 0.0.0.26 from ever being accepted. EXAMPLES Sample Host Configurations The gated.conf file for end systems is simple, usually containing only two configuration statements. The following sample configuration file emulates routed, runs RIP, and only sends updates if there is more than one interface up and IP forwarding is enabled in the kernel: # rip yes ; # Note that RIP will not run if UDP checksums are disabled in the kernel. The following sample gated.conf file runs RIP in quiet mode; it only listens to packets, no matter how many interfaces are configured: # rip yes ; { nobroadcast ; } ; # The following sample gated.conf file is suitable for any system that runs RIP and has only one network interface: # # do not time-out the network interface # interface 136.66.12.2 passive ; # # enable rip # rip yes ; # The passive keyword prevents gated from changing the preference of the route to this interface if it is believed to be down due to lack of received routing information. The interface passive statement identifies a router with a guest host on an Ethernet. In the previous example, the route is through the directly at- tached network interface. Normally when gated thinks an inter- face is down, it removes it from the routing database to prevent a gateway from announcing that it can route data through a non- operational interface. If the host has only one interface, it should not be removed from the routing database even if the interface is down (the in- terface 136.66.12.2 passive statement in the example. RIP is enabled with the rip yes statement. This statement is not re- quired as it is the default, but the explicit statement in the gated.conf file serves to document the configuration to prevent future confusion. RIP and EGP Configuration The following sample gated.conf file enables both an interior (RIP) and an exterior (EGP) protocol and sets certain protocol-specific parame- ters: # generate a default route if an EGP neighbor is acquired # op- tions gendefault ; # # define the autonomous system number for EGP # autonomoussystem 303 ; # # enable RIP # rip yes ; # # enable EGP with hello interval 1 1/2 minute, poll # interval 10 minutes, neighbors 26.6.0.103 and 26.20.0.72 # egp yes { packetsize 24488 ; group minhello 1:30 minpoll 10:00 { neighbor 26.6.0.103 ; neighbor 26.20.0.72 ; } ; } ; # # announce 136.66 to AS 183 # export proto egp as 183 { proto direct { 136.66 metric 0 ; } ; } ; # # announce default via RIP with a metric of 3 # export proto rip interface 136.66.12.1 { proto default { announce 0.0.0.0 metric 3 ; } ; } ; The AS number 303 is defined early because it is a definition statement and must occur before the first protocol statement. EGP is enabled by the yes keyword in the EGP statement, which also defines the following EGP parameters: the packetsize parameter, defining the initial size of update packets accepted; the group clause, setting parameters for all of the EGP neighbors in the group; and minhello and minpoll, setting the protocol timers. The first export statement directs gated to use EGP to advertise the network (136.66.0.0) to the Internet. This is the address of the net- work, not of a gateway. The second export statement is used to an- nounce the default route to subnet 136.66.12.0 with a metric of 3. BGP and OSPF Configuration The following sample gated.conf file implements the transformation of distance metrics between the internal (OSPF) and external (BGP) proto- cols. Autonomous system 1019, of which gated is a member, contains network 19.0.0.0. The gated machine has several interfaces into this autonomous system. The gated daemon is using BGP to peer with AS 2021, neighbor 21.5.1.21. /etc/gated.conf # # # # # # # # # # # # # # # # # # # interfaces {options all passive; }; autonomoussystem 1019; routerid 19.1.1.18; rip no; hello no; egp no; bgp yes { preference 50 ; group type External peeras 2021 { peer 21.5.1.21 ; } ; group type IGP peeras 1019 { peer 19.1.1.19 ; } ; } ; ospf yes { area 0.0.0.2 { authtype none; networks { 119.0.0.0 mask 255.0.0.0 ; } ; interface 119.2.128.18 cost 1 { retransmitinterval 5; transitdelay 1; priority 1; hello interval 10; routerdeadinterval 40; } ; interface 119.4.128.18 cost 1 { retransmitinterval 5; transitdelay 1; priority 1; hellointerval 60; routerdeadinterval 180; } ; } ; backbone { authype none; interface 19.1.1.19 cost 1 { retransmitinterval 5; transitdelay 1; priority 1; hellointerval 60; routerdeadinterval 180; } ; } ; } ; export proto ospfase type 1 { proto bgp as 2021 { ALL metric 1; }; proto direct { ALL metric 1; }; } ; export proto bgp as 2021 { proto direct { ALL metric 1; } ; proto ospfase { ALL metric 1; } ; } ; In this example, two autonomous systems (one internal, one external) are directly connected through a router that is attached to a backbone speaking OSPF. The AS number 1019 is defined early as it is a defini- tion statement that occurs again in the first protocol statement, which enables BGP. The first export statement directs gated to advertise routes from the internal group AS 1019 running OSPF as the IGP gather- ing routing information to the external group AS 2021 using BGP. Routes to two local Ethernets in AS 1019, identified as 119.2.128.18 and 119.4.128.18 (119.0.0.0 mask 255.0.0.0), are advertised along with the OSPF backbone (19.1.1.19). The parameters for AS path, path ori- gin, and transitive optional attributes, including transmission inter- vals, are defined. The second export statement announces the default route to AS 2021 with a metric of 1. Sample Interior Gateway Configurations Gateway configurations are more complicated than a simple host configu- ration as gateways have multiple interfaces and may run multiple proto- cols. This section contains sample gated.conf files for the following gateway configurations: RIP only (subnet to backbone) RIP with default announcement RIP and OSPF OSPF Using NBMA Mode RIP only (subnet to backbone) The following sample gated.conf file connects two networks within an autonomous system. You can use this configuration file for any gateway that uses only RIP and that connects a single subnet to a larger net- work. # # enable rip # rip yes ; # # using rip, announce subnet 3 via interface 136.66.1.2 # export proto rip interface 136.66.1.2 { proto direct { announce 136.66.3.0 metric 0 ; } ; } ; # # using rip, announce all routes learned from interface 136.66.1.2 # export proto rip interface 136.66.3.1 { proto rip interface 136.66.1.2 { announce all ; } ; } ; In this example, the first export statement tells gated to announce, via the RIP protocol and interface 136.66.1.2, a direct route to subnet 136.66.3.0. The second export statement announces to subnet 3 all routes learned from the interface 136.66.1.2, including subnet routes and any routes to the rest of the world, as well as default routes. The first export statement is not required because by default gated an- nounces every network that is directly connected to the gateway. The export statement was explicitly entered for two reasons: to document the intended structure and to avoid relying on defaults that might be changed in future releases. In any export statement, the main proto clause and the main interface clause may define the protocol and interface through which the routes are advertised. Subsidiary proto and interface clauses define the pro- tocols and the interfaces from which the routes must be learned. RIP with default announcement In the following sample gated.conf file, the gateway announces a de- fault route to the backbone and announces all of the individual subnet routes to the outside world. # # enable rip # rip yes ; # # using rip, announce all local subnets via 136.66.12.3 # export proto rip in- terface 136.66.12.3 metric 3 { proto rip interface 136.66.1.5 { announce all ; } ; }; # # using rip, announce default to the local backbone via 136.66.1.5 # export proto rip interface 136.66.3.1 { proto rip interface 136.66.12.3 { announce 0.0.0.0 ; } ; } ; The first export statement statement explicitly directs gated to an- nounce all of the routes it learns from interface 136.66.1.5 out through interface 136.66.12.3. The explicit announce all is not re- quired. The metric value is specified in the main statement and ap- plies to every route announced via this protocol and interface. When the metric is specified in the export clause, it only applies to the routes specified in that clause. In the previous example, metric 3 ap- plies to every route announced over interface 136.66.12.3 via RIP. RIP and OSPF The following sample gated.conf file for AS 283 enables both RIP and OSPF protocols and can be used for testing RIP and OSPF. #options noinstall ; interfaces { interface le0 passive ; } ; autonomoussystem 283 ; snmp yes ; rip yes { broadcast ; defaultmetric 5 ; interface le version 2 multicast ; } ; ospf yes { traceoptions 1sabuild protocol ; monauthkey "ZZZZZZZZ" ; backbone { authtype simple ; interface all { priority 2 ; } ; interface le { authkey "YYYYYYYY" ; } ; } ; } ; static { default gateway 132.236.200.200 preference 140 retain ; } In the RIP case, version 2 multicast packets are generated on all Eth- ernet interfaces (for example, le0, le1, and so on). This is a safe way to test RIP because the production gateways on this network do not support RIP version 2. In the OSPF case, all interfaces are configured to be Priority 2, so the Proteon routers (Priority 0) become designated routers. A simple password is specified "YYYYYYYY" for authentication of all Ethernet interfaces. (The only kind of interfaces in this con- figuration.) OSPF Using NBMA Mode In the following sample gated.conf file, a server is configured as both the area border router and the backbone router: traceoptions parse ; routerid 195.1.1.2 ; # RIP no ; OSPF yes { defaults { preference 10 ; cost 5 ; type 1 ; } ; area 0.0.0.1 { networks { 195.1.1.0 ; } ; interface 195.1.1.2 nnnbrn`dcast { routers { 195.1.1.1 eligible ; 195.1.1.2 eligible ; } ; priority 15 ; enable ; hellointerval 30 ; routerdeadinterval 30 ; pollinterval 30 ; } ; } ; area 0.0.0.2 { networks { 193.2.1.0 ; 194.1.1.0 ; } ; interface 194.1.1.3 nonbroadcast { routers { 194.1.1.2 eligible ; 194.1.1.3 eligible ; 194.1.1.1 ; } ; priority 15 ; enable ; hellointerval 30 ; routerdeadinterval 30 ; retransmitinterval 30 ; pollinterval 30 ; } ; } ; backbone { interface 15.13.115.156 nonbroadcast { enable ; transitdelay 20 ; priority 10 ; hellointerval 30 ; routerdeadinterval 30 ; retransmitinterval 30 ; pollinterval 30 ; } ; } ; } ; RELATED INFORMATION Daemons: gated(8). Files: gated.control(4), gated.proto(4). Networking: gated_intro(7). RFC 827, Exterior Gateway Protocol EGP, E. Rosen. RFC 891, DCN local-network protocols, D. Mills. RFC 904, Exterior Gateway Protocol Formal Specification, D. Mills. RFC 1058, Routing Information Protocol, C. Hedrick. RFC 1105, Border Gateway Protocol BGP, K. Lougheed, Y. Rekhter. RFC 1163, A Border Gateway Protocol (BGP), K. Lougheed, Y. Rekhter. RFC 1164, Application of the Border Gateway Protocol in the Internet, J. Honig, D. Katz, M. Mathis, Y. Rekhter, J. Yu. RFC 1227, SNMP MUX Protocol and MIB, M. Rose. RFC 1245, OSPF Protocol Analysis, J. Moy. RFC 1246, Experience with the OSPF Protocol, J. Moy. RFC 1253, OSPF Version 2 Management Information Base, F. Baker, R. Coltun. RFC 1256, ICMP Router Discovery Messages, S. Deering. RFC 1265, BGP Protocol Analysis, Y. Rekhter. RFC 1266, Experience with the BGP Protocol, Y. Rekhter. RFC 1267, A Border Gateway Protocol 3 (BGP-3), K. Lougheed, Y. Rekhter. RFC 1268, Application of the Border Gateway Protocol in the Internet, P. Gross, Y. Rekhter. RFC 1269, Definitions of Managed Objects for the Border Gateway Proto- col (Version 3), J. Burruss, S. Willis. RFC 1321, The MD5 Message-Digest Algorithm, R. Rivest. RFC 1370, Internet Architecture Board Applicability Statement for OSPF RFC 1388, RIP Version 2 Carrying Additional Information, G. Malkin. RFC 1397, Default Route Advertisement In BGP2 And BGP3 Versions Of The Border Gateway Protocol, D. Haskin. RFC 1403, BGP OSPF Interaction, K. Varadhan. RFC 1583, OSPF Version 2, J. Moy. delim off gated.conf(4)