Content-type: text/html Man page of ogated.conf

ogated.conf

Section: Devices and Network Interfaces (4)
Index Return to Main Contents
 

NAME

ogated.conf - Contains configuration information for the ogated daemon  

SYNOPSIS

/etc/ogated.conf  

DESCRIPTION

The /etc/ogated.conf file contains configuration information that is read by the ogated daemon at initialization time. This file contains stanzas that control tracing options, select routing protocols, manage routing information, and manage independent system routing.

Stanzas can appear in any order in the ogated.conf file. The following sections describe the format of each stanza.  

Controlling Trace Output

The option that controls trace output is read during the initialization of the ogated daemon and whenever the ogated daemon receives a SIGHUP signal. This option is overridden at initialization time if trace flags are specified to the ogated daemon on the command line.

The traceflags stanza is in the following format; it tells the ogated daemon what level of trace output you want. traceflags Flag [Flag Flag ...]

The valid flags for tracing are as follows: Logs all internal errors and interior routing errors Logs all external errors due to Exterior Gateway Protocol (EGP), exterior routing errors, and EGP state changes Logs all routing changes Traces all EGP packets sent and received Logs all routing updates sent Traces all Routing Information Protocol (RIP) packets received Traces all HELLO packets received Prints a timestamp to the log file every 10 minutes Combines the internal, external, route, and egp flags Enables all of the listed trace flags

If more than one traceflags stanza is used, the trace flags specified in all stanzas are enabled.  

Selecting Routing Protocols

This section explains the configuration options for routing protocols. These options provide the ogated daemon with instructions on how to manage routing for each protocol.

All references to point-to-point interfaces in the ogated configuration file must use the address specified by the Destination parameter.

Using the ogated Daemon with the RIP Protocol

The following stanza tells the ogated daemon how to perform the RIP routing protocol. RIP Argument Only one of the following RIP Arguments is allowed after the RIP keyword. Since only the first argument is recognized if more than one is specified, choose the argument that describes the type of RIP routing you need. A list of the arguments to the RIP stanza follows: Performs the RIP protocol, processing all incoming RIP packets and supplying RIP information every 30 seconds only if there are two or more network interfaces. Specifies that the RIP protocol not be performed. Performs the RIP protocol, processing all incoming RIP packets and forcing the supply of RIP information every 30 seconds no matter how many network interfaces are present. Performs the RIP protocol, processing all incoming RIP packets and forcing the supply of RIP information every 30 seconds no matter how many network interfaces are present. When this argument is specified, RIP information is not sent out in a broadcast packet. The RIP information is sent directly to the gateways listed in the sourceripgateways stanza. Processes all incoming RIP packets, but does not supply any RIP information no matter how many network interfaces are present. Processes all incoming RIP packets, supplying RIP information every 30 seconds and announcing the default route (network 0.0.0.0) with a metric specified by the HopCount variable. The metric should be specified in a value that represents a RIP hop count.

With this option set, all other default routes coming from other RIP gateways are ignored. The default route is only announced when actively peering with at least one EGP neighbor and therefore should only be used when EGP is used.

If no RIP stanza is specified, RIP routing is not performed.

Using the ogated Daemon with the HELLO Protocol

The following stanza configures the Defense Communications Network Local Network Protocol (HELLO) routing protocol for the ogated daemon: HELLO Argument The Argument variable parallels the RIP arguments, with some minor differences.

As with RIP, only one of the following HELLO Arguments is allowed after the HELLO keyword. Since only the first argument is recognized if more than one is specified, choose the argument that describes the type of RIP routing you need.

A list of the arguments to the HELLO stanza follows: Performs the HELLO protocol, processing all incoming HELLO packets and supplying HELLO information every 15 seconds only if there are two or more network interfaces. Specifies that this gateway does not perform the HELLO protocol. Performs the HELLO protocol, processing all incoming HELLO packets and forcing a supply of HELLO information every 15 seconds no matter how many network interfaces are present. Performs the HELLO protocol, processing all incoming HELLO packets and forcing a supply of HELLO information every 15 seconds no matter how many network interfaces are present.

When this argument is specified, HELLO information is not sent out in a broadcast packet. The HELLO information is sent directly to the gateways listed in the sourcehellogateways stanza. Processes all incoming HELLO packets, but does not supply any HELLO information regardless of the number of network interfaces present. Processes all incoming HELLO packets, supplying HELLO information every 15 seconds and announcing the default route (network 0.0.0.0) with a time delay specified by the MilliSeconds variable. The time delay should be a numeric value specified in milliseconds.

The default route is only announced when actively peering with at least one EGP neighbor. Therefore, this stanza should only be used when running EGP.

If no HELLO stanza is specified, HELLO routing is not performed.

Using the ogated Daemon with the EGP Protocol

The following stanzas specify the information necessary for the ogated daemon to use EGP. This stanza allows the processing of EGP by the ogated daemon to be turned on or off. The arguments are interpreted as follows: Performs all EGP operations. Specifies that no EGP processing should be performed.

Note that EGP processing takes place by default. If no EGP stanza is specified, all EGP operations take place. When the ogated daemon performs the EGP protocol, this stanza must be used to specify the independent (autonomous) system number. If this number is not specified, the ogated daemon exits immediately with an error message. When the ogated daemon performs the EGP protocol, this stanza specifies the number of EGP peers with whom the ogated daemon performs EGP. The Number variable must be a value greater than zero and less than or equal to the number of EGP neighbors specified, or the ogated daemon exits immediately. If this stanza is omitted, all EGP neighbors are acquired.

When the ogated daemon performs the EGP protocol, this stanza specifies with whom the ogated daemon is to perform EGP. The gateway specified by the Gateway variable can be either a host address in Internet dotted-decimal notation or a symbolic name from the /etc/hosts file.

Each EGP neighbor should have its own egpneighbor stanza and is acquired in the order listed in the ogated.conf file.

The arguments to the egpmaxacquireNumber stanza have the following definitions: Specifies the internal time delay to be used as a metric for all of the routes learned from this neighbor. The Delay variable should be specified as a time delay from 0 to 30,000. If this keyword and the validate keyword are not used, the internal metric used is the EGP distance multiplied by 100. Sets the EGP distance used for all networks advertised to this neighbor. The EGPMetric variable should be specified as an EGP distance in the range of 0 to 255. If this keyword is not specified, the internal time delay for each route is converted to an EGP distance divided by 100, with distances greater than 255 being set to 255. Verifies the autonomous system number of this neighbor. If the AutonomousSystem number specified in neighbor acquisition packets does not verify, an error message is generated refusing the connection. If this keyword is not specified, no verification of autonomous system numbers is done. Specifies the autonomous system number in EGP packets sent to this neighbor. If an ASout stanza is not specified, the AutonomousSystem number specified in the autonomoussystem stanza is used. This stanza is reserved for a special situation that occurs between the ARPANET network and National Science Foundation (NSF) networks, and is not normally used. Specifies that this neighbor should not be considered for the internal generation of a default when the RIP gateway or the HELLO gateway argument is used. If not specified, the internal default is generated when actively peering with this neighbor. Indicates that the default route (network 0.0.0.0) should be considered valid when received from this neighbor. If this keyword is not specified, on reception of the default route, the ogated daemon displays a warning message and ignores the route. Specifies that the internally generated default may be passed to this EGP neighbor at the specified distance. The distance should be specified as an EGP distance from 0 to 255. A default route learned from another gateway is not propagated to an EGP neighbor.

Without this keyword, no default route is passed through EGP. The acceptdefault keyword should not be specified when the defaultout keyword is used. The EGP metric specified in the egpmetricout keyword does not apply when the defaultout keyword is used. The default route always uses the metric specified by the defaultout keyword. Specifies that all networks received from this EGP neighbor must be defined in a validAS stanza that also specifies the autonomous system of this neighbor. Networks without a validAS stanza are ignored after a warning message is printed. Defines the interface used to send EGP packets to this neighbor. This keyword is only used when there is no common net or subnet with this EGP neighbor. This keyword is present for testing purposes and does not imply correct operation when peering with an EGP neighbor that does not share a common net or subnet. Specifies the source network to be used in EGP poll packets sent to this neighbor. If this keyword is not specified, the network (not subnet) of the interface used to communicate with this neighbor is used. This keyword is present for testing purposes and does not imply correct operation when used.
 

Managing Routing Information

The following configuration file stanzas determine how the ogated daemon handles both incoming and outgoing routing information.

Specifying RIP or HELLO Gateways to Which the ogated Daemon Listens

When the following stanzas are specified, the ogated daemon only listens to RIP or HELLO information, respectively, from these RIP or HELLO gateways: trustedripgateways Gateway [Gateway Gateway ...] trustedhellogateways Gateway [Gateway Gateway ...]

The Gateway variable may be either an Internet address in dotted-decimal notation, which avoids confusion, or a symbolic name from the /etc/hosts file. Note that the propagation of routing information is not restricted by this stanza.

Specifying Gateways for the ogated Daemon to Send RIP or HELLO Information

With the following stanzas, the ogated daemon sends RIP or HELLO information directly to the gateways specified: sourceripgateways Gateway [Gateway Gateway ...] sourcehellogateways Gateway [Gateway Gateway ...]

If the pointopoint argument is specified in the RIP or HELLO stanzas defined earlier, the ogated daemon sends only RIP or HELLO information to the specified gateways and does not send out any information using the broadcast address.

If the pointopoint argument is not specified in those stanzas and the ogated daemon is supplying RIP or HELLO information, the ogated daemon sends information to the specified gateways and also broadcasts information using a broadcast address.

Turning Routing Protocols On and Off by Interface

The following stanzas turn routing protocols on and off by interface: noripoutinterface InterfaceAddress
                    [InterfaceAddressInterfaceAddress ...] nohellooutinterface InterfaceAddress
                    [InterfaceAddressInterfaceAddress ...] noripfrominterface InterfaceAddress
                    [InterfaceAddressInterfaceAddress ...] nohellofrominterface InterfaceAddress
                    [InterfaceAddressInterfaceAddress ...]

A noripfrominterface or nohellofrominterface stanza means that no RIP or HELLO information is accepted coming into the listed interfaces from another gateway.

A noripoutinterface or nohellooutinterface stanza means that no RIP or HELLO knowledge is sent out of the listed interfaces. The InterfaceAddress variable should be an Internet address in dotted-decimal notation.

Stopping the ogated Daemon from Timing Out Interfaces

The following stanza stops the ogated daemon from timing out the interfaces whose addresses are listed in Internet dotted-decimal notation by the InterfaceAddress arguments. These interfaces are always considered up and working. passiveinterfaces InterfaceAddress
                    [InterfaceAddressInterfaceAddress... ]

This stanza is used because the ogated daemon times out an interface when no RIP, HELLO, or EGP packets are being received on that particular interface, in order to dynamically determine if an interface is functioning properly.

Packet Switch Node (PSN) interfaces send a RIP or HELLO packet to themselves to determine if the interface is properly functioning, since the delay between EGP packets may be longer than the interface time-out. Interfaces that have timed out automatically have their routes reinstalled when routing information is again received over the interface.

If the ogated daemon is not a RIP or HELLO supplier, no interfaces are aged and the passiveinterfaces stanza automatically applies to all interfaces.

Specifying an Interface Metric

The following stanza allows the specification of an interface metric for the listed interface: interfacemetric InterfaceAddress Metric

On systems that support interface metrics, this stanza overrides the kernel's metric. On systems that do not support an interface metric, this feature allows one to be specified.

The interface metric is added to the true metric of each route that comes in with routing information from the listed interface. The interface metric is also added to the true metric of any information sent out through the listed interface. The metric of directly attached interfaces is also set to the interface metric, and routing information broadcast about directly attached networks is based on the interface metric specified.

The interfacemetric stanza is required for each interface on which an interface metric is desired.

Providing Hooks for Fallback Routing

The following stanza provides hooks for fallback routing in the ogated daemon: reconstmetric InterfaceAddress Metric

If this stanza is used, the metrics of the routes contained in any RIP information coming into the listed interface are set to the metric specified by the Metric variable. Metric reconstitution should be used carefully, since it could be a major contributor in the formation of routing loops. Any route that has a metric of infinity is not reconstituted and is left as infinity.

Note that the reconstmetric stanza should be used with extreme caution.

The following stanza also provides hooks for fallback routing for the ogated daemon: fixedmetric InterfaceAddress Protocol rip | hello Metric

If this stanza is used, all routing information sent out by the specified interface has a metric specified by the Metric variable. For RIP, specify the metric as a RIP hop count from 0 to infinity. For HELLO, specify the metric as a HELLO delay in milliseconds from 0 to infinity. Any route that has a metric of infinity is left as infinity.

Note that fixed metrics should be used with extreme caution.

Specifying Information to Be Ignored

The following stanza indicates that any information regarding the Network variable that comes in by means of the specified protocols and from the specified interfaces is ignored: donotlisten Network intf Address [Address... ] proto rip | hello donotlistenhost Host intf Address [Address... ] proto rip | hello

The donotlisten stanza contains the following information: the keyword donotlisten, followed by a network number specified by the Network variable, which should be in dotted-decimal notation, followed by the intf keyword. Next is a list of interfaces in dotted-decimal notation, then the proto keyword, followed by the rip or hello keyword.

The all keyword can be used after the intf keyword to specify all interfaces on the system. For example: donotlisten 10.0.0.0 intf 128.84.253.200 proto rip

means that any RIP information about network 10.0.0.0 coming in by interface 128.84.253.200 will be ignored. One stanza is required for each network on which this restriction is desired. In addition: donotlisten 26.0.0.0 intf all proto rip hello

means that any RIP and HELLO information about network 26.0.0.0 coming in through any interface is ignored.

The donotlistenhost stanza is defined in the same way, except that a host address is provided instead of a network address. Restrictions on routing updates are applied to the specified host route learned through the specified routing or protocols.

Specifying Network or Host Information to Which the ogated Daemon Listens

The following stanzas indicate that the ogated daemon should listen to specified protocols and gateways: listen Network gateway Address [Address... ] proto rip | hello listenhost Host gateway Address [Address... ] proto rip | hello

The listen and listenhost stanzas specify to listen only to information about a network or host on the specified protocol or protocols and from the listed gateways.

These stanzas read as follows: the listen or listenhost keyword is followed by a network or host address, respectively, in dotted-decimal notation. Next is the gateway keyword with a list of gateways in dotted-decimal notation, and then the proto keyword followed by the rip or hello keyword. For example: listen 128.84.0.0 gateway 128.84.253.3 proto hello

indicates that any HELLO information about network 128.84 that comes in through gateway 128.84.253.3 is accepted. Any other information about network 128.84 from any other gateway is rejected. One stanza is needed for each net to be restricted.

Also, the stanza: listenhost 26.0.0.15 gateway 128.84.253.3 proto rip

means that any information about host 26.0.0.15 must come through RIP from gateway 128.84.253.3. All other information regarding this host is ignored.

Restricting Announcements of Networks and Hosts

The following stanzas allow restriction of the networks and hosts that are announced and the protocols that announce them: announce Network InterfaceAddress [Address... ]
                         Protocol Type [EGPMetric] announcehost Host InterfaceAddress Protocol
                         Type [EGPMetric] noannounce Network InterfaceAddress [Address . . . ]
                         Protocol Type [EGPMetric] noannouncehost Host InterfaceAddress Protocol
                         Type [EGPMetric]

The announce{host} and noannounce{host} stanzas cannot be used together on the same interface. With the announce{host} stanza, the ogated daemon only announces the networks or hosts that have an associated announce or announcehost stanza with the appropriate protocol.

With the noannounce{host} stanza, the ogated daemon announces everything, except those networks or hosts that have an associated noannounce or noannouncehost stanza. These stanzas provide a choice of announcing only what is on the announce list or everything, except those networks on the noannounce list on an individual basis.

The arguments are the same as in the donotlisten stanza, except that egp may be specified in the Proto field. The Type can be rip, hello, egp, or any combination of the three. When egp is specified in the Proto field, an EGP metric must be specified. This is the metric at which the ogated daemon announces the listed network through EGP.

Note that these are not static route entries. These restrictions only apply if the network or host is learned through one of the routing protocols. If a restricted network suddenly becomes unreachable and goes away, announcement of this network stops until it is learned again.

Only one announce{host} or noannounce{host} stanza may be specified for each network or host. A network or host cannot, for instance, be announced through HELLO for one interface and through RIP for another.

Some sample announce stanzas might include: announce 128.84 intf all proto rip hello egp egpmetric 0 announce 10.0.0.0 intf all proto rip announce 0.0.0.0 intf 128.84.253.200 proto rip announce 35.0.0.0 intf all proto rip egp egpmetric 3

With only these four announce stanzas in the configuration file, the ogated process only announces these four networks. Network .84.0.0 is announced through RIP and HELLO to all interfaces and through EGP with a metric of 0 (zero). Network .0.0.0 is announced through RIP to all interfaces.

Network 0.0.0.0 (default) is announced by RIP through interface 128.84.253.200 only. Network 35.0.0.0 is announced through RIP to all interfaces and announced through EGP with a metric of 3. These are the only networks that are broadcast by this gateway.

Once the first announce stanza is specified, only the networks with announce stanzas are broadcast, including local subnetworks. Once an announce{host} or noannounce{host} stanza has an all keyword specified after an intf keyword, that stanza is applied globally and the option of having individual interface restrictions is lost.

If no routing announcement restrictions are desired, announce stanzas should not be used. All information learned is then propagated out. That announcement has no affect on the information to which the ogated daemon listens.

Any network that does not have an announce stanza is still added to the kernel routing tables, but it is not announced through any of the routing protocols. To stop networks from being added to the kernel, the donotlisten stanza may be used.

As another example: announce 128.84 intf 128.59.2.1 proto rip noannounce 128.84 intf 128.59.1.1 proto rip

indicates that on interface 128.59.2.1, only information about network 128.84.0.0 is announced through RIP, but on interface 128.59.1.1, all information is announced, except 128.84.0.0 through RIP.

The stanzas: noannounce 128.84 intf all proto rip hello egp egpmetric 0 noannounce 10.0.0.0 intf all proto hello

mean that except for the two specified networks, all networks are propagated. Specifically, network 128.84.0.0 is not announced on any interface through any protocols. Knowledge of network 128.84.0.0 is not sent anywhere. Network 10.0.0.0 is not announced through HELLO to any interface.

The second stanza also implies that network 10.0.0.0 is announced to every interface through RIP. This network is also broadcast through EGP with the metric specified in the defaultegpmetric stanza.

Defining a Default EGP Metric

The following stanza defines a default EGP metric to use when there are no routing restrictions: defaultegpmetric Number Without routing restrictions, the ogated daemon announces all networks learned through HELLO or RIP through EGP with this specified default EGP metric. If this stanza is not used, the default EGP metric is set to 255, which causes any EGP advertised route of this nature to be ignored.

When there are no routing restrictions, any network with a direct interface is announced through EGP with a metric of 0 (zero). Note that this does not include subnetworks, but only the nonsubnetworked network.

Defining a Default Gateway

The following stanza defines a default gateway, which is installed in the kernel routing tables during initialization and reinstalled whenever information about the default route is lost:
defaultgateway Gateway [Metric] Protocol
                                   [active | passive]

This route is installed with a time delay equivalent to a RIP metric of 15, unless another metric is specified with the Metric variable.

If the RIP gateway or HELLO gateway is in use, this default route is deleted.

An active default route is overridden by any other default route learned through another routing protocol. A passive default route is only overridden by a default route with a lower metric. In addition, an active default route is not propagated in routing updates, while a passive default route is propagated.

The gateway specified by the Gateway variable should be an address in Internet dotted-decimal notation. The Metric variable is optional and should be a time delay from 0 to 30,000. If a Metric is not specified, a time delay equivalent to a RIP metric of 15 is used.

The Protocol variable should be either rip, egp, or hello. The Protocol variable initializes the protocol by which the route was learned. In this case the Protocol variable is unused but remains for consistency.

Installing a Static Route

The following stanzas install static routes: net NetworkAddress gateway Address metric HopCount rip | egp | hello host HostAddress gateway Address metricHopCount rip | egp | hello

The net and host stanzas install a static route to the network specified by the NetworkAddress variable or the host specified by the HostAddress variable. The route is through a gateway specified by the Address variable at a metric specified by the HopCount variable learned through RIP, HELLO, or EGP. Again, dotted-decimal notation should be used for the addresses. These routes are installed in the kernel's routing table and are never affected by any other gateway's RIP or HELLO announcements. The protocol by which they were learned is important if the route is to be announced through EGP.

If the protocol is RIP or HELLO and there are no routing restrictions, then this route is announced by EGP with a metric of defaultegpmetric. If the protocol keyword is egp and there are no routing restrictions, then this route is announced by EGP with a metric specified by the HopCount variable.

Restricting EGP Announcements

The following stanza provides a soft restriction to the ogated daemon: egpnetsreachable Network [Network Network . . . ]

It cannot be used when the announce or noannounce stanzas are used. With no restrictions, the ogated daemon announces all routes learned from RIP and HELLO through EGP. The egpnetsreachable stanza restricts EGP announcement to those networks listed in the stanza.

The metric used for routes learned through HELLO and RIP is the value given in the defaultegpmetric stanza. If this stanza does not specify a value, the value is set to 255. With the egpnetsreachable stanza, unique EGP metrics cannot be set for each network. The defaultegpmetric is used for all networks, except those that are directly connected, which use a metric of 0 (zero).

Specifying Invalid Networks

The following stanza appends to the ogated daemon's list of martian networks, which are those that are known to be invalid and should be ignored: martiannets Network [Network Network . . . ]

When the ogated daemon receives information about one of these networks through any means, it immediately ignores it. If external tracing is enabled, a message is printed to the trace log. Multiple occurrences of the martiannets stanza accumulate.

The initial list of martian networks provided by the ogated daemon contains the following networks: 127.0.0.0, 128.0.0.0, 191.253.0.0, 192.0.0.0, 223.255.255.0, and 224.0.0.0.  

Managing Autonomous System Routing

In the internal routing tables, the ogated daemon maintains the autonomous system number from which each route was learned. Independent (autonomous) systems are used only when an exterior routing protocol is in use, in this case EGP.

Routes are tagged with the autonomous system number of the EGP peer from which they were learned. Routes learned through the interior routing protocols, RIP and HELLO, are tagged with the autonomous system number specified in the autonomoussystem stanza of the ogated.conf file.

The ogated server does not normally propagate routes learned from exterior routing protocols to interior routing protocols, since some gateways do not have adequate validation of routing information they receive. Some of the following stanzas allow exterior routes to be propagated through interior protocols. Therefore, it is imperative that utmost care be taken when allowing the propagation of exterior routes.

The following stanzas provide limited control over routing based on autonomous system numbers.

Validating Networks from an Independent (Autonomous) System

The following stanza is used for validation of networks from a certain independent system: validAS Network AS System metric Number

When an EGP update is received from a neighbor that has the validate keyword specified in the associated egpneighbor stanza, a search is made for a validAS stanza that defines the network and the autonomous system number of the EGP neighbor.

If the appropriate validAS stanza is located, the network is considered for addition to the routing table with the specified metric. If a validAS stanza is not located, a warning message is printed and the network is ignored.

A network may be specified in several validAS stanzas as being associated with several different autonomous systems.

Controlling Exchange of Routing Information Between Autonomous Systems

The following stanzas control routing information exchange: announcetoAS AutonomousSystem1 ASlist AutonomousSystem2
                                     [AutonomousSystem3... ] noannouncetoAS AutonomousSystem1 ASlist AutonomousSystem2
                                     [AutonomousSystem3... ]

The announcetoAS and noannouncetoAS stanzas control the exchange of routing information between different autonomous (independent) systems. Normally, the ogated daemon does not propagate routing information between independent systems.

The exception to this is that routes learned from the ogated daemon's own independent system through RIP and HELLO are propagated through EGP. These stanzas allow information learned through EGP from one autonomous system to be propagated through EGP to another autonomous system or through RIP and HELLO to the ogated daemon's own autonomous system.

If the announcetoAS stanza is specified, information learned through EGP from autonomous systems AS1, AS2, AS3, and so on, is propagated to autonomous system AS0. If the ogated daemon's own autonomous system, as specified in the autonomoussystem stanza, is specified as AS0, this information is propagated through RIP and HELLO. Routing information from autonomous systems not specified in the ASlist are not propagated to autonomous system AS0.

If the noannouncetoAS stanza is specified, information learned through EGP from all autonomous systems, except AS1, AS2, AS3, and so on, is propagated to autonomous system AS0. If the ogated daemon's own autonomous system is specified as AS0, this information is not propagated through RIP and HELLO.

Only one announcetoAS or noannounceAS stanza may be specified for each target autonomous system.  

EXAMPLES

An example ogated.conf file for a ogated server that performs only EGP routing might contain the following entries. The following three lines specify which protocol will be running. RIP and HELLO do not run. EGP does run. RIP no HELLO no EGP yes #

The traceflags stanza tells what level of trace output is desired: Logs all internal error and interior routing errors. Logs all external errors due to EGP, exterior routing errors, and EGP state changes. Logs all routing changes. Traces all EGP packets sent and received. Logs all routing updates.

The autonomous system stanza specifies the autonomous system number. This must be specified if running EGP. traceflags internal external route egp update autonomoussystem 178

The following egpneighbor stanza specifies with whom you are going to perform EGP. This line says that your EGP neighbor is the host 192.100.9.1. The defaultegpmetric stanza specifies that when there are no routing restrictions, the default EGP metric is 132. egpneighbor 192.100.9.1 defaultegpmetric 132 #

The next line indicates that for network 192.200.9 the gateway is 192.101.9.3 with a hop count of 50 when using RIP protocol. This is a static route.

The egpnetsreachable stanza restricts EGP announcements to those networks listed: net 192.200.9 gateway 192.101.9.3 metric 50 rip egpnetsreachable 192.200.9 192.101.9

The following lists the static routes, showing the host address, gateway address, hop count, and protocol used: # Static routes host 129.140.46.1 gateway 192.100.9.1 metric 5 rip host 192.102.9.2 gateway 192.100.9.1 metric 5 rip host 192.104.9.2 gateway 192.100.9.1 metric 5 rip host 149.140.3.12 gateway 192.100.9.1 metric 5 rip host 129.140.3.12 gateway 192.100.9.1 metric 5 rip host 129.140.3.13 gateway 192.100.9.1 metric 5 rip host 129.140.3.14 gateway 192.100.9.1 metric 5 rip host 192.3.3.54 gateway 192.101.9.3 metric 5 rip  

RELATED INFORMATION

Daemons: ogated(8) delim off


 

Index

NAME
SYNOPSIS
DESCRIPTION
Controlling Trace Output
Selecting Routing Protocols
Managing Routing Information
Managing Autonomous System Routing
EXAMPLES
RELATED INFORMATION

This document was created by man2html, using the manual pages.
Time: 02:40:04 GMT, October 02, 2010