GateD Configuration-GTDCFGxx
Available Languages
Table Of Contents
GateD Configuration Member—(GTDCFGxx)
GateD Configuration—GTDCFGxx
This chapter outlines the configuration information needed to configure the GateD routing protocol. It contains these sections:
•
GateD Configuration Member—(GTDCFGxx)
Introduces the GateD configuration member
Describes GateD statement classes
Describes the GateD statement primitives
Describes the GateD directive statements
Describes the GateD trace statements
Describes the GateD options statements
Describes the GateD interfaces statements
Describes the GateD definition statement.
Describes the GateD protocol statements
Describes the Route protocol statements
Describes the Control protocol statements
GateD Configuration Member—(GTDCFGxx)
Use the GTDCFGxx member to specify configuration parameters for the GateD routing protocol. To activate GateD, specify GATED(xxxx) on the IP statement, where xxxx is the GTDCFGxx member you wish to use.
The GateD configuration member is very different from most other configuration files for Cisco IOS for S/390. It consists of a sequence of statements, each terminated by a semi-colon (;). Statements are composed of tokens separated by white space (any combination of blanks, tabs, and newlines). Comments use the "C style" comment which starts with a "/*" and continues until it reaches "*/".
Note
GateD relies heavily on functions and features native to UNIX operating systems. These functions and features are emulated on MVS by Cisco IOS for S/390 or by the SAS/C runtime library. References to the UNIX kernel in this section refer to Cisco IOS for S/390 itself and not the MVS operating system. For information about various function routines generally native to UNIX read:
•
•
•
•
Virtual IP Addressing is available with Fault Tolerant operation. For more information, read Virtual IP Addressing, in .
Statement Classes
There are eight classes of statements. The first two classes, directives and trace, may be specified in the configuration file in any order. The remaining six classes must be specified in the order shown.
directives
These statements are immediately acted upon by the parser. They are used to specify included files and the directory in which they reside. Unlike other statements which terminate with a semi-colon (;), directive statements terminate with a newline.
trace
These statements control tracing options.
options
These statements allow specification of some global options.
interface
These statements specify interface options.
definition
These statements specify options, the autonomous system and martian networks.
protocol
These statements enable or disable protocols and set protocol options.
route
Static routes are defined by route statements.
control
Control statements define routes that are imported from routing peers and routes that are exported to these peers.
Statement Primitives
The primitives that can be used in the GateD statements are described below and outlined in the sections that follow.
host
Any host. A host may be specified by its IP address or by a domain name. If a domain name is specified that has multiple IP addresses, it is considered an error. The host bits in the IP address must be non-zero.
network
Any network. A network may be specified by its IP address or a network name. The host bits in a network specification must be zero. default may also be used to specify the default network (0.0.0.0).
destination
Any host or network.
dest_mask
Any host or network with an optional mask:
allnetworknetwork mask masknetwork mask-length bitshost hostA mask is a dotted quad specifying which bits of the destination are significant. All may be used to specify that any IP address may be matched. The number of contiguous bits may be used instead of an explicit mask.
autonomous system
A number between 1 and 65534 assigned by the Internet Assigned Numbers Authority to represent an autonomous system.
gateway
A gateway must be a host on an attached network.
interface
An interface can be specified by IP address, domain name, or interface name.
Interface names for Cisco IOS for S/390 are assigned as follows:
Table 17-1
Interface Names for Cisco IOS for S/390
Additional interfaces have the same name incremented by 1 (in other words, a second Ethernet interface would be en1).
To force GateD to use a specific device, you must use the routerid statement. Read Definition Statements for more information.
gateway_list
A gateway list is a list of one or more gateways.
interface_list
An interface list is a list of one or more interface names, wildcard names (names without a number) or addresses, or the token all, which refers to all interfaces.
preference
A preference is used to determine the order of routes to the same destination in the routing table. GateD allows one route to a destination per protocol/per autonomous system. In the case of multiple routes, the route to use is chosen by preference, which is a number between 0 and 255, with 0 being the most preferred and 255 being the least preferred.
In case of a preference tie, if the two routes are from the same protocol and from the same autonomous system, GateD will choose the route with the lowest metric. Otherwise GateD will choose the route with the lowest numeric next-hop gateway address.
metric
A valid metric for the specified protocol.
Directive Statements
Use directive statements to specify included files and the directory in which they reside. Unlike other statements which terminate with a semicolon (;), directive statements terminate with a newline. Directive statements are acted upon immediately by the parser.
This statement causes the specified file to be parsed completely before resuming with this file:%include "ddn:ddname(MEMBER)".
Nesting is supported up to 10 levels.
options gendefault;%include "ddn:sysparm(GTDRIP)"traceoptions none;If a member named GTDRIP in a data set in the sysparm DD concatenation exists with this data
rip yes;the above example will parse as follows:
options gendefault;rip yes;traceoptions none;Trace Statements
Trace statements control tracing options for GateD. This is how trace statements are used:
traceoptions traceoption [traceoption [...]]
[except traceoption [traceoption [... ]]];
If none is the only option specified, tracing is turned off. If except is specified, flags listed before it are turned on and flags listed after it are turned off. Use this to turn on all but a few flags. The trace flags are described below:
Options Statements
The options statement allows specification of some global GateD options. This is how options statements are used:
options option_list;
Syntax Description
Interfaces Statements
Use this syntax to specify interface options:
interfaces {
options [strictifs] [scaninterval time];
interface interface_list interface_options ;
define address [broadcast broadaddr | pointopoint lcladdr]
[netmask netmask] [multicast];
} ;
Syntax Description
options
Sets some global options related to interfaces. Options are:
strictifs—Indicates that it is a fatal error to reference an interface in the configuration file that is not listed in a define statement or not present when GateD is started. Without this option, a warning message will be issued and GateD will continue.
scaninterval time—Specifies how often GateD scans the kernel interface list for changes. The default is every 15 seconds on most systems, 60 seconds on systems that pass interface status changes through the routing socket (in other words, BSD 4.4).
Note GateD will also scan the interface list on receipt of a PPOST USER.
interface
Sets interface options on the specified interfaces. An interface_list is all or a list of interface names (read the warning about interface names in the interface entry of the table in Statement Primitives), domain names, or numeric addresses. interface_options are:
preference pref—Sets the preference for routes to this interface when it is up, defaults to 0.
down preference pref—Sets the preference for routes to this interface when GateD believes it to be down due to lack of received routing information, defaults to 120 seconds.
passive—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.
simplex—Defines an interface as unable to hear its own broadcast packets. Currently defining an interface as simplex is functionally equivalent to defining it as passive.
reject—Specifies that the address loopback interfaces which match these criteria will be used as the local address when installing reject routes in the kernel. Should only be used with systems based on BSD 4.3 Tahoe or earlier which have installed a reject/blackhole pseudo interface.
blackhole—Specifies that the address loopback interfaces which match these criteria will be used as the local address when installing blackhole routes in the kernel. Should only used with systems based on BSD 4.3 Tahoe or earlier which have installed a reject/blackhbhole pseudo interface.
define
Defines interfaces that may not be present when GateD is started. GateD considers it an error to reference a non-existent interface in the configuration file. This clause allows specification of that interface so it can be referenced in the configuration file. Definition keywords are:
broadcast broadaddr—Defines the interface as broadcast capable (in other words, Ethernet and Token Ring) and specifies the broadcast address.
pointopoint lcladdr—Defines the interface as a point-to-point interface (in other words, SLIP and PPP) and specifies the address on the local side. For this type of interface the interface_addr specifies the address of the remote host.
An interface not defined as broadcast or point-to-point is assumed to be nonbroadcast multiaccess (NBMA).
Definition Statements
Definition statements specify options, the autonomous system, and martian networks.
This definition statement sets the autonomous system of this router to be autonomous system. This option is required if BGP or EGP are in use.
autonomoussystem autonomous system;
This definition statement sets the router identifier for use by the BGP and OSPF (Open Shortest Path First) protocols. The default is the address of the first interface encountered by GateD. The address of a non-POINTOPOINT interface is preferred over the local address of a POINTOPOINT interface and an address on a loopback interface that is not the loopback address (127.0.0.1) is most preferred. This statement forces GateD to use a specific device. (Read about the interface parameter in Statement Primitives).
routerid host;
Note
The martians statement defines a list of martian addresses about which all routing information is ignored. The martian_list is a semicolon-separated list of symbolic or numeric hosts with optional masks. Read the dest_mask entry of the table in Statement Primitives. The allow parameter can be specified to explicitly allow a subset of a range that was disallowed.
martians {martian_list};Protocol Statements
A protocol statement enables or disables the use of a protocol and controls protocol options. These statements can be specified in any order.
For all protocols, the preference option controls the choice of routes learned via this protocol or from this autonomous system in relation to routes learned from other protocols or autonomous systems.
The default metric used when propagating routes learned from other protocols is specified with defaultmetric, which itself defaults to the highest valid metric for this protocol. For many protocols this signifies a lack of reachability.
For distance vector IGPs with no explicit connections or authentication (RIP and HELLO) and redirects (ICMP), the trustedgateways clause supplies a list of gateways providing valid routing information; routing packets from other gateways are ignored. This defaults to all gateways on the attached networks.
Routing packets can be sent not only to the remote end of point-to-point links and the broadcast address of broadcast-capable interfaces, but also to specific gateways if they are listed in a sourcegateways clause and yes or on is specified. If nobroadcast is specified, routing updates will be sent only to gateways listed in the sourcegateways clause, and not to the broadcast address.
Use the interface clause to disable transmission and reception of routing packets for a particular protocol. Override an interface clause that disables sending or receiving protocol packets for specific peers with the trustedgateways and sourcegateways clauses.
For exterior protocols (BGP, EGP), the autonomous system advertised to the peer is specified by the global autonomoussystem clause unless overridden by the asout parameter. The incoming autonomous system number is not verified unless peeras is specified.
Specifying metricout fixes the outgoing metric for all routes propagated to this peer. If the peer does not share a network, use interfaces to specify which interface address to use when communicating with this peer, and use gateway to specify the next hop to use for all routes learned from this peer. An internal default is generated when routing information is learned from a peer unless the nogendefault parameter is specified.
Any protocol can have a traceoptions clause, which enables tracing for a particular protocol, group, or peer. Table 17-2 shows the allowable protocol-specific options.
Table 17-2 Protocol Trace Options
RIP Protocol Configuration
The section describes how to configure GateD for RIP (Routing Information Protocol). If the RIP clause is not specified, the default is rip on.
rip yes | no | on | off [ {
broadcast;
nobroadcast;
nocheckzero;
preference preference;
defaultmetric metric;
interface interface_list [noripin] [noripout]
[metricin metric] [metricout metric]
[version 1]|[version 2 broadcast]
[authentication [none | password]];
...
trustedgateways gateway_list;
sourcegateways gateway_list;
traceoptions traceoptions;
} ] ;
Syntax Description
OSPF Protocol Configuration
The section describes how to configure GateD for the OSPF protocol. If the OSPF clause is not specified, the default is ospf off.
The OSPF statement is shown below:
ospf yes | no | on | off [ {
[defaults {
preference preference ;
cost cost ;
tag [tag | as [as_tag]] ;
type 1|2 ;
}] ;
[exportlimit routes ; ]
[exportinterval time ; ]
[traceoptions traceoptions ; ]
[monitorauthkey authkey ; ]
[area area | backbone
{
authtype 0 | 1 | none | simple ;
stub [cost cost];
networks {network [mask mask] ;} ;
stubhosts {host cost cost ;} ;
interface interface [cost cost] {
[enable | disable] ;
retransmitinterval time ;
transitdelay time ;
priority priority ;
hellointerval time ;
routerdeadinterval time ;
authkey auth_key ;
} ;
interface interface nonbroadcast [cost cost] {
pollinterval time ;
routers {gateway [eligible] ... } ;
[enable | disable] ;
retransmitinterval time ;
transitdelay time ;
priority priority ;
hellointerval time ;
routerdeadinterval time ;
authkey auth_key ;
} ;
; ]
virtuallink neighborid routerid transitarea area {
[enable | disable] ;
retransmitinterval time ;
transitdelay time ;
priority priority ;
hellointerval time ;
routerdeadinterval time ;
authkey auth_key ;
} ;
. . .
} ] ;
Syntax Description
The sub-parameters for the OSPF statement are:
Usage Notes for OSPF
•
•
•
•
HELLO Protocol Configuration
The section describes how to configure GateD for the HELLO protocol. If the HELLO clause is not specified, the default is hello off.
Note
hello yes | no | on| off [ {
broadcast;
nobroadcast;
preference preference;
defaultmetric metric;
interface interface_list [nohelloin] [nohelloout]
[metricin metric] [metricout metric] ;
...
trustedgateways gateway_list;
sourcegateways gateway_list;
traceoptions traceoptions;
} ] ;
Syntax Description
EGP Protocol Configuration
The section describes how to configure GateD for EGP (External Gateway Protocol). If the EGP clause is not specified, the default is egp off. The egp statement is shown below:
Note
egp yes | no | on | off [ {
[preference preference ; ]
[defaultmetric metric ; ]
[packetsize maxpacketsize ; ]
[traceoptions traceoptions ; ]
[group [peeras autonomous system]
[localas autonomous system]
[maxup number]
[preference preference]
{
neighbor host
[metricout metric]
[nogendefault]
[importdefault]
[exportdefault]
[gateway gateway]
[ lcladdr local_address]
[sourcenet network]
[minhello min_hello]
[minpoll min_poll]
[traceoptions traceoptions]
;
...
} ;
...]
} ] ;
Syntax Description
BGP Protocol Configuration
The section describes how to configure GateD for BGP (Border Gateway Protocol). If the BGP clause is not specified, the default is bgp off. The bgp statement is shown below:
bgp yes | no | on | off [ {
[preference preference ; ]
[defaultmetric metric ; ]
[traceoptions traceoptions ; ]
[group type external | internal | igp | test peeras peeras
[metricout metric]
[localas localas]
[nogendefault]
[gateway gateway]
[preference preference]
[lcladdr local_address]
[holdtime time]
[traceoptions traceoptions ]
[version version]
[passive]
[importdefault]
[exportdefault]
[sendbuffer bufsize]
[recvbuffer bufsize]
[spoolbuffer bufsize]
[keepall]
{
[allow {dest_mask ... } ; ]
[peer host
[metricout metric]
[localas localas]
[nogendefault]
[gateway gateway]
[preference preference]
[lcladdr local_address]
[holdtime time]
[traceoptions traceoptions]
[version version]
[passive]
[importdefault]
[exportdefault]
[sendbuffer bufsize]
[recvbuffer bufsize]
[spoolbuffer bufsize]
[keepall]
; ]
...
} ;
....]
} ] ;
Syntax Description
Any number of group clauses can be specified containing any number of neighbor clauses. Any parameters from the neighbor clause can be specified on the group clause to provide defaults for the group.
BGP peers are assigned to groups based on the type and peeras, it is not possible to have two groups with the same type and peeras. Group options provide the defaults for all peers within that group.
The local_address specifies the address to be used on the local end of the TCP connection with the peer. For external peers the local address must be on an interface which is shared with the peer (or for a non-local peer's configured next-hop gateway when the gateway option is used to specify this) and a session with the peer will be opened only when an interface with the appropriate local address through which the peer (gateway) address is directly reachable is operating. For other types of peers, a peer session will be maintained when any interface with the specified local address is operating. In either case, incoming connections will only be recognized as matching a configured peer if they are addressed to the configured local address.
The options sendbuffer, recvbuffer, and spoolbuffer are normally not needed on properly functioning systems.
ICMP Redirect Configuration
By configuring the redirect statement, you control whether GateD makes routing table changes based on ICMP redirects when not functioning as a router. When functioning as a router (in other words, any interior routing protocols (RIP, HELLO, OSPF) are participating in routing on any interface), ICMP redirects are disabled. When ICMP redirects are disabled, GateD must actively remove the effects of redirects from the kernel as the kernel always processes ICMP redirects.
redirect yes | no | on | off [ {
preference preference;
interface interface_list [noredirects] ;
trustedgateways gateway_list ;
traceoptions traceoptions ;
} ] ;
Syntax Description
yes | no | on | off
Turns ICMP redirects on or off.
Default: off
preference
Controls the choice of routes learned via this protocol or from this autonomous system in relation to routes learned from other protocols or autonomous systems. Default is 30.
interface interface_list [noredirects]
Sets interface options on the specified interfaces. An interface list is all or a list of interface names (read the warning about interface names in the interface entry of the table in Statement Primitives), domain names, or numeric addresses. The interface_list option is a list of one or more interface names, wildcard names (names without a number) or addresses, or the token all, which refers to all interfaces. The noredirects option excludes the interface specified.
trustedgateways
Override an interface clause that disables sending or receiving protocol packets for specific peers.
traceoptions
Enable tracing for a particular protocol, group, or peer.
Route Statements
Any number of static statements can be specified, each containing any number of static route definitions. The first form (the first section of the example below) defines a static route through one or more gateways. If multiple gateways are specified, they are limited by the number of multipath destinations supported (on UNIX this is almost always one). Only gateways on interfaces that are configured and up are used.
The interface list on the first form restricts static routes to a specific set of interfaces.
The second form (the second section of the example below) defines a static interface route which is used for primitive support of multiple networks on one interface.
In this example the retain parameter causes the route to be retained in the kernel after GateD is shut down. The reject parameter causes all packets to this route to be rejected. The blackhole parameter causes all packets to this route to be silently discarded.
static {dest_mask gateway gateway [gateway2 [gateway3 [...]]][interface interface_list][preference preference][retain] [reject] [blackhole] [noinstall] ;...dest_mask interface interface [preference preference] [retain][reject] [blackhole] [noinstall] ;...} ;The preference for static routes defaults to 60.
Note
Control Statements
Control statements define routes that are imported from routing peers and routes that are exported to these peers. This section describes the use of the import and export statements.
Import Statements
An import_list consists of zero or more destinations (with optional mask). One of two parameters may be specified; restrict to prevent a set of destinations from being imported, or a specific preference for this set of destinations.
dest_mask [[restrict] | [preference preference]];
The contents of an import_list are sorted internally so that entries with the most specific masks are examined first. The order in which dest_mask entries are specified does not matter.
If no import list is specified, all routes will be accepted. If an import list is specified, the import list is scanned for a match. If no match is found, the route is discarded. Rephrased, an all restrict entry is assumed in an import list.
import proto bgp|egp as autonomous system restrict ;import proto bgp|egp as autonomous system[preference preference] {import_list} ;import proto bgp aspath aspath_spec restrict ;import proto bgp aspath aspath_spec[preference preference] {import_list} ;import proto rip|hello|redirect restrict ;import proto rip|hello|redirect[preference preference] {import_list} ;import proto rip|hello|redirect interface interface_list restrict ;import proto rip|hello|redirect interface interface_list[preference preference] {import_list} ;import proto rip|hello|redirect gateway gateway_list restrict ;import proto rip|hello|redirect gateway gateway_list[preference preference] {import_list} ;import proto ospfase [tag ospf_tag] restrict ;import proto ospfase [tag ospf_tag][preference preference] [{import_list}] ;If an OSPF type is specified, only routes of that type will be considered for import, otherwise either type will be considered. If an ospf_tag specification is given, only routes matching that tag specification will be considered, otherwise any tag will be considered. An OSPF tag specification is a decimal, hexadecimal or dotted quad number.
If more than one import statement relevant to a protocol is specified, they are processed most specific to least specific (in other words, for RIP and HELLO, gateway, interface, and protocol), then in the order specified in the configuration file.
Export Statements
The export_list specifies exportation based on the origin of a route to a destination:
export proto bgp|egp as autonomous system restrict ;export proto bgp|egp as autonomous system[metric metric] {export_list} ;export proto rip|hello restrict ;export proto rip|hello [metric metric] {export_list} ;export proto rip|hello interface interface_list restrict ;export proto rip|hello interface interface_list[metric metric] {export_list} ;export proto rip|hello gateway gateway_list restrict ;export proto rip|hello gateway gateway_list[metric metric] {export_list} ;export proto ospfase [type 1|2] [tag ospf_tag] restrict ;export proto ospfase [type 1|2] [tag ospf_tag][cost ospf_cost] {export_list} ;The following export statements demonstrate the use of a tag to specify particular routes.
proto bgp|egp as autonomous system[restrict] | [metric metric] [ {announce_list} ] ;proto rip|hello|direct|static|default[restrict] | [metric metric] [ {announce_list} ] ;proto rip|hello|direct|static|default interface interface_list[restrict] | [metric metric] [ {announce_list} ] ;proto rip|hello gateway gateway_list[restrict] | [metricmetric] [ {announce_list} ] ;proto ospf [restrict] | [metric metric] [ {announce_list ;} ] ;proto ospfase [restrict | metric metric]] [ {announce_list ;} ] ;proto proto aspath aspath_spec[restrict] | [metric metric] [ {announce_list} ] ;proto proto tag tag[restrict] | [metric metric] [ {announce_list} ] ;If a tag is specified, only routes with that tag will be considered, otherwise any tag will be considered. An OSPF tag on an export statement may be a decimal, hexadecimal, or AS to generate a tag based on the AS path of route being announced. An OSPF tag on an export list is just a 31 bit number that is matched against the tag present (if any) on that route.
If more than one export statement relevant to a protocol is specified, they are processed most specific to least specific (in other words, for RIP and HELLO, gateway, interface and protocol), then in the order specified in the configuration file.
By default, interface routes are exported to all protocols. RIP and HELLO also export their own routes. An export specification with just a restrict will prevent these defaults from being exported.
Note
Any protocol may be specified for import lists referring to aspaths and tags. AS paths are most meaningful with BGP and OSPF ASE routes, but are generated for all routes. tags are currently only meaningful for OSPF ASE routes.
An announce_list consists of zero or more destinations (with optional mask). One of two parameters may be specified, restrict to prevent a set of destinations from being exported or a specific metric for this set of destinations.
dest_mask [[restrict] | [metric metric]];Note that the contents of an announce_list are sorted internally so that entries with the most specific masks are examined first. The order in which dest_mask entries are specified does not matter.
If no announce_list is specified, all destinations are announced. If an announce list is specified, an all restrict is assumed. Therefore, an empty announce list is the equivalent of all restrict.
Note
An AS path specification (aspath_spec) is used to match one or more AS paths.
aspath regexp origin [igp|egp|incomplete|any]where the regexp is a regular expression over the set of AS numbers as defined in RFC-1164 section 4.2.
Feedback