gated.proto - Gate daemon configuration file (protocol
statements)
Routing protocols determine the "best" route to each destination
and distribute routing information among the systems
on a network. Routing protocols are divided into two
general groups: interior (intra-domain) and exterior
(inter-domain) protocols. The gated software combines management
of the interior and exterior routing protocols in
one software daemon.
Intra-Domain Routing Protocols [Toc] [Back]
Intra-domain (interior) protocols are used to exchange
reachability information within an autonomous system (AS).
They are referred to as a class by the acronym IGP. The
following interior protocols are supported: The Routing
Information Protocol, Version 1 and Version 2, is the most
commonly used interior protocol. RIP selects the route
with the lowest metric as the best route. The metric is a
hop count representing the number of gateways through
which data must pass to reach its destination. The
longest path that RIP accepts is 15 hops. If the metric is
greater than 15, a destination is considered unreachable
and gated discards the route. RIP assumes the best route
is the one that uses the fewest gateways (the shortest
path), not taking into account congestion or delay on
route.
The RIP version 1 protocol is described in RFC
1058; the RIP version 2 protocol is described in
RFC 11723. Open Shortest Path First (OSPF) is a
link-state protocol. OSPF is better suited than
RIP for complex networks with many routers. OSPF
provides equal cost multipath routing.
OSPF is described in RFC 2178; OSPF Version 2 is
described in RFC 1583. The OSPF Version 2 MIB is
defined in RFC 1850. Other related documents are
RFC 1245, RFC 1246, and RFC 1370.
Exterior Routing Protocols [Toc] [Back]
Exterior protocols are used to exchange routing information
between autonomous systems. Exterior protocols are
only required when an autonomous system must exchange
routing information with another autonomous system.
Routers within an autonomous system run an interior routing
protocol like RIP. Only those gateways that connect
an autonomous system to another autonomous system need to
run an exterior routing protocol. The following exterior
protocols are supported by gated: Exterior Gateway Protocol
(EGP). Originally EGP reachability information was
passed into ARPANET/MILNET "core" gateways where the best
routes were chosen and passed back out to all connected
autonomous systems. As the Internet moved toward a less
hierarchical architecture, EGP, an exterior routing protocol
that assumes a hierarchical structure, became less
effective.
The EGP protocol is described in RFC 827 and RFC
904. Border Gateway Protocol (BGP) is replacing
EGP as the exterior protocol of choice. BGP
exchanges reachability information between
autonomous systems, but provides more capabilities
than EGP. BGP uses path attributes to provide more
information about each route as an aid in selecting
the best route. Path attributes can include, for
example, administrative preferences based on political,
organizational, or security (policy) considerations
in the routing decision. BGP supports
nonhierarchical topologies and can be used to
implement a network structure of equivalent
autonomous systems.
BGP version 1 is described in RFC 1105, version 2
in RFC 1163, version 3 in RFC 1267, and version 4
in RFC 1771. The version 3 MIB is described in RFC
1269. The documents RFC 1164, RFC 1268, and RFC
1772 describe the application of version 2, 3, and
4 in the Internet. A protocol analysis of and
experience with BGP version 3 are available in RFC
1265 and RFC 1266. RFC 1397 talks about advertising
a default route in BGP version 2 and 3.
The BGP-4 MIB is draft standard, but schedule to go
to standard. Other references for BGP are: RFC 1997
for BGP Communities, RFC 1966 for BGP Route Reflection,
RFC 1966 for BGP AS Confederations, and RFC
1403 for BGP - OSPF interaction. A useful application
document is RFC 1998, "An Application of the
BGP Community Attribute in Multi-home Routing".
Other Routing Protocols [Toc] [Back]
The following routing protocol is also supported: The
Router Discovery protocol is used to inform hosts of the
availability of hosts it can send packets to and is used
to supplement a statically configured default router. This
is the preferred protocol for hosts to run, they are discouraged
from wiretapping routing protocols.
Router Discovery is described in RFC 1256.
Routing Information Protocol (RIP) [Toc] [Back] One of the most widely used interior gateway protocols is
the Routing Information Protocol (RIP). RIP is an implementation
of a distance-vector, or Bellman-Ford routing
protocol for local networks. It classifies routers as
active and passive (silent). Active routers advertise
their routes (reachability information) to others; passive
routers listen and update their routes based on advertisements,
but do not advertise. Typically, routers run RIP
in active mode, while hosts use passive mode.
A router running RIP in active mode broadcasts updates at
set intervals. Each update contains paired values where
each pair consists of an IP network address and an integer
distance to that network. RIP uses a hop count metric to
measure the distance to a destination. In the RIP metric,
a router advertises directly connected networks at a metric
of 1. Networks that are reachable through one other
gateway are two hops, and so on. Thus, the number of hops
or hop count along a path from a given source to a given
destination refers to the number of gateways that a datagram
encounters along that path. Using hop counts to calculate
shortest paths does not always produce optimal
results. For example, a path with hop count 3 that
crosses three Ethernets might be substantially faster that
a path with a hop count 2 that crosses two slow-speed
serial lines. To compensate for differences in technology
many routers advertise artificially high hop counts for
slow links.
As delivered with most UNIX systems, RIP is run by the
routing daemon, routed (pronounced route-"d"). A RIP
routing daemon dynamically builds on information received
through RIP updates. When started, it issues a REQUEST
for routing information and then listens for responses to
the request. If a system configured to supply RIP hears
the request, it responds with a RESPONSE packet based on
information in its routing database. The RESPONSE packet
contains destination network addresses and the routing
metric for each destination.
When a RIP RESPONSE packet is received, the routing daemon
takes the information and rebuilds the routing database
adding new routes and better (lower metric) routes to destinations
already listed in the database. RIP also
deletes routes from the database if the next router to
that destination says the route contains more than 15
hops, or if the route is deleted. All routes through a
gateway are deleted if no updates are received from that
gateway for a specified time period. In general, routing
updates are issued every 30 seconds. In many implementations,
if a gateway is not heard from for 180 seconds, all
routes from that gateway are deleted from the routing
database. This 180 second interval also applies to deletion
of specific routes.
RIP version 2 (more commonly known as RIP II) adds capabilities
to RIP. Some of these capabilities are compatible
with RIP I and some are not. To avoid supplying
information to RIP I routes that could be misinterpreted,
RIP II can only use non-compatible features when its packets
are multicast. On interfaces that are not capable of
IP multicast, RIP I-compatible packets are used that do
not contain potentially confusing information.
The following is a list of main RIP II enhancements: The
primary ones are the ability to advertise a next hop to
use other than the router supplying the routing update.
This is quite useful when advertising a static route to a
dumb router that does not run RIP as it avoids having
packets destined through the dumb router from having to
cross a network twice.
RIP I routers ignore next hop information in RIP II
packets. This might result in packets crossing a
network twice, which is exactly what happens with
RIP I. So this information is provided in RIP Icompatible
RIP II packets. RIP I assumes that all
subnetworks of a given network have the same network
mask. It uses this assumption to calculate
the network masks for all routes received. This
assumption prevents subnets with different netmasks
from being included in RIP packets. RIP II adds
the ability to explicitly specify the network mask
with each network in a packet.
While RIP I routers will ignore the network mask in
RIP II packets, their calculation of the network
mask will quite possibly be wrong. For this reason,
RIP I-compatible RIP II packets must not contain
networks that would be misinterpreted. These
network must only be provided in native RIP II
packets that are multicast.
RIP-I derives the network mask of received networks
and hosts from the network mask of the interface
the packet via which the packet was received. If a
received network or host is on the same natural
network as the interface over which it was received
and that network is subnetted (the specified mask
is more specific than the natural netmask), the
subnet mask is applied to the destination. If bits
outside the mask are set it is assumed to be a
host, otherwise it is assumed to be a subnet.
On point-to-point interfaces, the netmask is
applied to the remote address. The netmask on
these interfaces is ignored if it matches the natural
network of the remote address or is all ones.
Unlike in previous releases, the zero subnet mask
(a network that matches the natural network of the
interface, but has a more specific, or longer, network
mask) is ignored. If this is not desirable, a
route filter can be used to reject it. RIP II
packets can also contain one of two types of
authentication string that can be used to verify
the validity of the supplied routing data. Authentication
can be used in RIP I-compatible RIP II
packets, but be aware that RIP I routers ignore it.
The first method is a simple password in which an
authentication key of up to 16 characters is
included in the packet. If this does not match
what is expected, the packet will be discarded.
This method provides very little security as it is
possible to learn the authentication key by watching
RIP packets.
The second method uses the MD5 algorithm to create
a crypto-checksum of a RIP packet and an authentication
key of up to 16 characters. The transmitted
packet does not contain the authentication key
itself, instead it contains a crypto-checksum,
called the digest. The receiving router will perform
a calculation using the correct authentication
key and discard the packet if the digest does not
match. In addition, a sequence number is maintained
to prevent the replay of older packets.
This method provides a much stronger assurance that
routing data originated from a router with a valid
authentication key.
Two authentication methods can be specified per
interface. Packets are always sent using the primary
method, but received packets are checked with
both the primary and secondary methods before being
discarded. In addition, a separate authentication
key is used for non-router queries.
RIP Syntax [Toc] [Back]
rip yes | no | on | off [ {
broadcast ;
nobroadcast ;
nocheckzero ;
preference preference ;
defaultmetric metric ;
query authentication [none | [[simple|md5] password]]
;
interface interface_list
[noripin] | [ripin]
[noripout] | [ripout]
[metricin metric]
[metricout metric]
[version 1]|[version 2 [multicast|broadcast]]
[[secondary] authentication [none | [[simple|md5]
password]] ;
trustedgateways gateway_list ;
sourcegateways gateway_list ;
traceoptions trace_options ; } ] ;
The rip statement enables or disables RIP. If the rip
statement is not specified the default is rip on;. If
enabled, RIP assumes nobroadcast when there is only one
interface and broadcast when there is more than one. The
following rip options are supported: Specifies that RIP
packets are broadcast regardless of the number of interfaces
present. This is useful when propagating static
routes or routes learned from anther protocol into RIP.
In some cases, the use of broadcast when only one network
interface is present can cause data packets to traverse a
single network twice. Specifies that RIP packets are not
broadcast on attached interfaces, even if there are more
than one. If a sourcegateways clause is present, routes
are unicast directly to that gateway. Specifies that RIP
should not make sure that reserved fields in incoming version
1 RIP packets are zero. Normally RIP rejects packets
when the reserved fields are zero. Sets the preference
for routes learned from RIP. The default preference is
100. This preference can be overridden by a preference
specified in import policy. Defines the metric used when
advertising routes via RIP that were learned from other
protocols. If not specified, the default value is 16
(unreachable). This choice of values requires you to
explicitly specify a metric in order to export routes from
other protocols into RIP. This metric can be overridden by
a metric specified in export policy. Specifies the
authentication required of query packets that do not originate
from routers. The default is none. Controls various
attributes of sending RIP on specific interfaces. See
the Interface Lists section in gated.conf(4) for the
description of the interface_list.
Note that if there are multiple interfaces configured
on the same subnet, RIP updates are sent from
first one on which RIP output is configured.
The following interface parameters are supported:
Specifies that RIP packets received via the specified
interface are ignored. The default is to listen
to RIP packets on all non-loopback interfaces.
This is the default. This argument might be necessary
when noripin is used on a wild card interface
descriptor. Specifies that no RIP packets are sent
on the specified interfaces. The default is to
send RIP on all broadcast and non-broadcast interfaces
when in broadcast mode. The sending of RIP
on point-to-point interfaces must be manually configured.
This is the default. This argument is
necessary when it is desired to send RIP on pointto-point
interfaces and might be necessary when
noripin is used on a wild card interface descriptor.
Specifies the RIP metric to add to incoming
routes before they are installed in the routing
table. The default is the kernel interface metric
plus 1 (which is the default RIP hop count). If
this value is specified, it is used as the absolute
value, the kernel metric is not added. This option
is used to make this router prefer RIP routes
learned via the specified interface(s) less than
RIP routes from other interfaces. Specifies the
RIP metric to be added to routes that are send via
the specified interface(s). The default is zero.
This option is used to make other routers prefer
other sources of RIP routes over this router.
Specifies that RIP packets sent via the specified
interface(s) are version 1 packets. This is the
default. Specifies that RIP version 2 packets are
sent on the specified interfaces(s). If IP multicast
support is available on this interface, the
default is to send full version 2 packets. If it
is not available, version 1 compatible version 2
packets are sent. Specifies that RIP version 2
packets should be multicast on this interface.
This is the default. Specifies that RIP version
1-compatible version 2 packets should be broadcast
on this interface, even if IP multicast is available.
Defines the authentication type to use. It
applies only to RIP version 2 and is ignored for
RIP-1 packets. The default authentication type is
none. If a password is specified, the authentication
type defaults to simple. The password should
be a quoted string with between 0 and 16 characters.
If secondary is specified, this defines the secondary
authentication. If omitted, the primary
authentication is specified. The default is primary
authentication of none and no secondary
authentication. Defines the list of gateways from
which RIP will accept updates. The gateway_list is
a list of host names or IP addresses. By default,
all routers on the shared network are trusted to
supply routing information. But if the trustedgateways
clause is specified, only updates from
the gateways in the list are accepted. Defines a
list of routers to which RIP sends packets
directly, not through multicast or broadcast. This
can be used to send different routing information
to specific gateways. Updates to gateways in this
list are not affected by noripout on the interface.
Specifies the tracing options for RIP. (See the
Trace Options Statement section in gated.conf(4)
and the RIP-specific tracing options that follow.)
RIP Tracing options [Toc] [Back]
The policy option logs info whenever a new route is
announced, the metric being announced changes, or a route
goes or leaves holddown. The following packet tracing
options, which can be modified with detail, send, or recv,
are supported: All RIP packets. RIP information request
packets, such as REQUEST, POLL and POLLENTRY RIP RESPONSE
packets, which is the type of packet that actually contains
routing information. Any other type of packet. The
only valid ones are TRACE_ON and TRACE_OFF both of which
are ignored.
Open Shortest Path Routing (OSPF) is a shortest path first
(SPF) or link-state protocol. OSPF is an interior gateway
protocol that distributes routing information between
routers in a single autonomous system. OSPF chooses the
least cost path as the best path. Suitable for complex
networks with a large number of routers, OSPF provides
equal cost multipath routing where packets to a single
destination can be sent via more than one interface simultaneously.
In a link-state protocol, each router maintains a database
describing the entire AS topology, which it builds out of
the collected link state advertisements of all routers.
Each participating router distributes its local state (the
router's usable interfaces and reachable neighbors)
throughout the AS by flooding. Each multiaccess network
that has at least two attached routers has a designated
router and a backup designated router. The designated
router floods a link state advertisement for the multiaccess
network and has other special responsibilities. The
designated router concept reduces the number of adjacencies
required on a multiaccess network.
OSPF allows networks to be grouped into areas. Routing
information passed between areas is abstracted, potentially
allowing a significant reduction in routing traffic.
OSPF uses four different types of routes, listed in
order of preference: intra-area, inter-area, type 1 external
and type 2 external. Intra-area paths have destinations
within the same area, inter-area paths have destinations
in other OSPF areas and Autonomous System External
(ASE) routes are routes to destinations external to the
AS. Routes imported into OSPF as type 1 routes are supposed
to be from igps whose external metrics are directly
comparable to OSPF metrics. When a routing decision is
being made, OSPF adds the internal cost to the AS Border
router to the external metric. Type 2 ASEs are used for
egps whose metrics are not comparable to OSPF metrics. In
this case, only the internal OSPF cost to the AS Border
router is used in the routing decision.
From the topology database, each router constructs a tree
of the shortest paths with itself as the root. This
shortest-path tree gives the route to each destination in
the AS. Externally derived routing information appears on
the tree as leaves. The link-state advertisement format
distinguishes between information acquired from external
sources and information acquired from internal routers, so
there is no ambiguity about the source or reliability of
routes. Externally derived routing information (for example,
routes learned from EGP or BGP) is passed transparently
through the autonomous system and is kept separate
from OSPF's internally derived data. Each external route
can also be tagged by the advertising router, enabling a
passing of additional information between routers on the
borders of the autonomous system.
OSPF optionally includes type of service (TOS) routing and
allows administrators to install multiple routes to a
given destination for each type of service (for example,
low delay or high throughput). A router running OSPF uses
the destination address and the type of service to choose
the best route to the destination.
OSPF intra- and inter-area routes are always imported into
the gated routing database with a preference of 10. It
would be a violation of the protocol if an OSPF router did
not participate fully in the area's OSPF, so it is not
possible to override this. Although it is possible to
give other routes lower preference values explicitly, it
is ill-advised to do so.
Hardware multicast capabilities are also used where possible
to deliver link-status messages. OSPF areas are connected
by the backbone area, the area with identifier
0.0.0.0. All areas must be logically contiguous and the
backbone is no exception. To permit maximum flexibility,
OSPF allows the configuration of virtual links enable the
backbone area to appear contiguous despite the physical
reality.
All routers in an area must agree on that area's parameters.
A separate copy of the link-state algorithm is run
for each area. Because of this, most configuration parameters
are defined on a per area basis. All routers
belonging to an area must agree on that area's configuration.
Misconfiguration will lead to adjacencies not forming
between neighbors, and routing information might not
flow, or even loop.
Authentication [Toc] [Back]
All OSPF protocol exchanges can be authenticated. Authentication
guarantees that routing information is only
imported from trusted routers, to protect the Internet and
its users. A variety of authentication schemes can be
used but a single scheme must be configured for each
interface. This enables some interfaces to use much
stricter authentication than others. The following authentication
schemes are available: No authentication. To use
no authentication, add the following line to the appropriate
OSPF interface statements: auth none ; Simple authentication
key. Use this to prevent certain routers from
exchanging OSPF packets. The interfaces that the packets
are to be sent on still need to be trusted because the key
will be placed in the packets and can be seen by anyone
with access to the network.
To specify simple authentication, add the following
line to your OSPF interface statements: auth simple
auth_key; In the preceding line, auth_key is a
string of up to 8 characters, and is standardized.
MD5 authentication. Use this when you do not trust
other users of your network. This system works by
using shared secret keys. Because the keys are used
to sign the packets with an MD5 checksum, they cannot
be forged or tampered with. Because the keys
are not included in the packet, snooping the key is
not possible. Users of the network can still snoop
the contents of packets, however, because the packets
are not encrypted.
MD5 authentication is compliant with the OSPF specification
in RFC 2178. This specification uses the
MD5 algorithm and an authentication key of up to 16
characters. RFC 2178 allows multiple MD5 keys per
interface. Each key has two associated time ranges.
To specify a single MD5 key on an interface, add
the following to the appropriate OSPF interface
statements: auth md5 md5-key where md5-key is: key
your-key id id-number [ {
[ start-generate date-time ; ]
[ stop-generate date-time ; ]
[ start-accept date-time ; ]
[ stop-accept date-time ; ] } ] ; Where id-number
is an integer with a value between 1 and 255
and date-time is in the format YYYY/MM/DD HH:MM (If
any time fields are used, all are required).
If no value is given for the time ranges, the
default values are: key is always generated key is
always accepted
Thus, if you always want your key to be accepted,
simply specify a sequence such as: auth md5 key
"mikeyone" id 1; To specify multiple MD5 keys on an
interface, add the following to the appropriate
OSPF interface statements: auth md5 {
md5-key
md5-key
.
.
.
md5-key } ; For example, two routers may start
out generating key 1 and want to switch to key 2 at
6:00 GMT. In order to make the transition between
keys easier, the routers agree to stop generating
key 1 at 6:00 GMT, but accept key 1 until 6:10 GMT.
Key 2 is accepted 10 minutes before the planned
switch time (5:50 GMT). These overlapping ranges
allow the clocks on the routers to be slightly out
of syncronization. You can specify this sequence
of keys as follows: auth md5 {
key "mikeyone" id 1 {
stop-generate 1999/05/01 06:00;
stop-accept 1999/05/01 06:10;
};
key "mikeytwo" id 2 {
start-generate 1999/05/01 06:00;
start-accept 1999/05/01 05:50;
}; };
OSPF Syntax [Toc] [Back]
ospf yes | no | on | off [ {
defaults {
preference preference ;
cost cost ;
tag [as] tag ;
type 1 | 2 ;
inherit-metric ;
} ;
exportlimit routes ;
exportinterval time ;
traceoptions trace_options ;
syslog [first pktcnt][ every every_pktcnt] ;
monitorauthkey authkey ;
area area | backbone {
stub [cost cost] ;
networks {
network [restrict] ;
network mask mask [restrict] ;
network masklen number [restrict] ;
host host [restrict] ;
} ;
stubhosts {
host cost cost ;
} ;
interface interface_list; [cost cost] [ {
enable | disable ;
interface_parameters
} ] ;
interface interface_list nonbroadcast [cost cost] [
{
pollinterval time ;
routers {
gateway [eligible] ;
} ;
interface_parameters
} ] ;
Backbone only:
virtuallink neighborid router_id transitarea area {
interface_parameters
} ;
} ; } ] ; Specify the defaults used when importing
OSPF Autonomous System External (ASE) routes into the
gated routing table and exporting routes from the gated
routing table into OSPF ASEs. The preference is used to
determine how OSPF routes compete with routes from other
protocols in the gated routing table. The default value
is 150. The cost is used when exporting a non-OSPF route
from the gated routing table into OSPF as an ASE. The
default value is 1. This can be explicitly overridden in
export policy. OSPF ASE routes have a 32-bit tag field
that is not used by the OSPF protocol, but might be used
by export policy to filter routes. When OSPF is interacting
with an EGP, the tag field can be used to propagate AS
path information, in which case the as keyword is specified
and the tag is limited to 12 bits of information. If
not specified, the tag is set to zero. Routes exported
from the gated routing table into OSPF default to becoming
type 1 ASEs. This default can be explicitly changed here
and overridden in export policy. Enables an OSPF ASE
route to inherit the metric of the external route when no
metric is specified on the export. This option maintains
compatibility with all the current export functions: A
metric specified on the export will take precedence. The
cost specified in the default will be used if inherit-metric
is not specified. Because of the nature of OSPF, the
rate at which ASEs are flooded must be limited. The following
two parameters can be used to adjust those rate
limits: Specifies how often a batch of ASE link state
advertisements are generated and flooded into OSPF. The
default is once per second. Specifies how many ASEs are
generated and flooded in each batch. The default is 100.
Specifies the tracing options for OSPF. (See
gated.conf(4) and the OSPF tracing options section.)
Specifies the tracing options for logging OSPF packets.
The log will contain the first pkcnt packets for every
type of OSPF packet. After the first pckcnt packets, the
syslog will only save one message per every every_pktcnt
packets. OSPF state can be queried using the ospf_monitor
(This should be a hyperlink) utility. This utility sends
non-standard OSPF packets that generate a text response
from OSPF. By default, these requests are not authenticated;
if an authentication key is configured, the incoming
requests must match the specified authentication key.
No OSPF state can be changed by these packets, but the act
of querying OSPF can utilize system resources. Each OSPF
router must be configured into at least one OSPF area. If
more than one area is configured, at least one must the be
backbone. The backbone can only be configured using the
backbone keyword, it cannot be specified as area 0. The
backbone interface can be a virtuallink. A stub area is
one in which there are no ASE routes. If a cost is
specified, this injects a default route into the area with
the specified cost. The networks list describes the scope
of an area. Intra-area LSAs that fall within the specified
ranges are not advertised into other areas as interarea
routes. Instead, the specified ranges are advertised
as summary network LSAs. If restrict is specified, the
summary network LSAs are not advertised. Intra-area LSAs
that do not fall into any range are also advertised as
summary network LSAs. This option is very useful on well
designed networks in reducing the amount of routing information
propagated between areas. The entries in this list
are either networks or a subnetwork/mask pair. See the
section on "Route Filtering" in gated.control(4) for more
detail about specifying ranges. Specifies directly
attached hosts that should be advertised as reachable from
this router and the costs they should be advertised with.
Point-to-point interfaces on which it is not desirable to
run OSPF should be specified here.
It is also useful to assign an additional address
to the loopback interface (one not on the 127 network)
and advertise it as a stub host. If this
address is the same one used as the router-id, it
enables routing to OSPF routers by router-id
instead of by interface address. This is more
reliable than routing to one of the router's interface
addresses, which might not always be reachable.
This form of the interface clause is used to
configure a broadcast (which requires IP multicast
support) or a point-to-point interface. See the
"Interfaces Statement" section in gated.conf(4) for
the description of the interface_list parameters.
Each interface has a cost. The costs of all interfaces
a packet must cross to reach a destination
are summed to get the cost to that destination.
The default cost is one, but another non-zero value
can be specified.
This form has one unique parameter: Enables or disables
the interface. See the "Interface Parameters"
section for a list of parameters common to
all interface types. This form of the interface
clause is used to specify a nonbroadcast interface
on a non-broadcast multi-access (NBMA) medium.
Because an OSPF broadcast medium must support IP
multicasting, a broadcast-capable medium that does
not support IP multicasting must be configured as a
non-broadcast interface.
A non-broadcast interface supports any of the standard
interface clauses listed previously and the
following two that are specific to non-broadcast
interfaces: Before adjacency is established with a
neighbor, OSPF packets are sent periodically at the
specified poll interval. By definition, it is not
possible to send broadcast packets to discover OSPF
neighbors on a non-broadcast, so all neighbors must
be configured. The list includes one or more
neighbors and an indication of their eligibility to
become a designated router. See the "Interface
Parameters" section for a list of parameters common
to all interface types. Virtual links are used to
establish or increase connectivity of the backbone
area. The neighborid is the router_id of the other
end of the virtual link. The transit area
specified must also configured on this system. All
standard interface parameters defined by the interface
clause can be specified on a virtual link.
See the "Interface Parameters" section for a list
of parameters common to all interface types.
Interface Parameters [Toc] [Back]
The following interface parameters are common to all types
of interfaces: The number of seconds between link state
advertisement retransmissions for adjacencies belonging to
this interface. The estimated number of seconds required
to transmit a link state update over this interface. The
transitdelay parameter takes into account transmission and
propagation delays and must be greater than 0. A number
between 0 and 255 specifying the priority for becoming the
designated router on this interface. When two routers
attached to a network both attempt to become designated
router, the one with the highest priority wins. A router
whose router priority is set to 0 is ineligible to become
designated router. The length of time, in seconds,
between Hello packets that the router sends on the interface.
The length of time, in seconds, a router's neighbors
wait to hear a router's Hello packets before the they
declare the router down. Do not send or receive packets
on this interface. This has the effect of originating a
stub link to this interface into the domain. Used by OSPF
authentication to generate and verify the authentication
field in the OSPF header. The authentication key can be
configured on a per interface basis. It is specified by
one to eight decimal digits separated by periods, a oneto
eight-byte hexadecimal string preceded by 0x, or a one
to eight character string in double quotes. See the
"Authentication" section for additional information.
Specify MD5 authentication with the md5-key, which
is specified as: key auth-key id id-number [ {
[start-generate date-time;]
[stop-generate date-time;]
[start-accept date-time;]
[stop-accept date-time;] }]; Where auth-key is
a one-to-eight character string, id-number is an
integer with a value between 1 and 255, and datetime
is in the format YYYY/MM/DD HH:MM. If any
time fields are used, all are required.
See the "Authentication" section for additional
information. Used by OSPF authentication to generate
and verify the secondary authentication field
in the OSPF header. The authentication key can be
configured on a per-interface basis. It is specified
by one to eight decimal digits separated by
periods, a one-to-eight byte hexadecimal string
preceded by 0x, or a one-to-eight character string
in double quotes. See the "Authentication" section
for more information.
Point-to-point interfaces also support the following
parameter: By default, OSPF packets to neighbors
on point-to-point interfaces are sent via the
IP multicast mechanism. Some implementations of IP
multicasting for UNIX, however, have a bug that
precludes the use of IP multicasting on these
interfaces. The gated daemon detects this condition
and falls back to using sending unicast OSPF
packets to this point-to-point neighbor.
If the use of IP multicasting is not desired
because the remote neighbor does not support it,
the nomulticast parameter can be specified to force
the use of unicast OSPF packets. You can also use
this option to eliminate warnings when gated
detects the previously described bug.
OSPF Tracing options [Toc] [Back]
In addition to the following OSPF specific trace flags,
OSPF supports the state that traces interface and neighbor
state machine transitions. Creates the Link State Advertisement
Traces the link state packets transmitted Traces
the link state packets received Traces the Shortest Path
First (SPF) calculations Traces OSPF at the debugging
level of detail The following packet tracing options,
which can be modified with detail, send, and recv, are
supported: OSPF HELLO packets, which are used to determine
neighbor reachability. OSPF Database Description packets,
which are used in synchronizing OSPF databases. OSPF Link
State Request packets, which are used in synchronizing
OSPF databases. OSPF Link State Update packets, which are
used in synchronizing OSPF databases. OSPF Link State Ack
packets, which are used in synchronizing OSPF databases.
The Exterior Gateway Protocol (EGP) [Toc] [Back] The Exterior Gateway Protocol (EGP) is an exterior routing
protocol used for exchanging routing information with
gateways in other autonomous systems. Unlike interior
protocols, EGP propagates only reachability indications,
not true metrics. EGP updates contain metrics, called
distances, that range from 0 to 255. The gated daemon compares
EGP distances learned from the same AS.
Before EGP sends routing information to a remote router,
it must establish an adjacency with that router. This is
accomplished by an exchange of Hello (not to be confused
with the HELLO protocol or OSPF HELLO messages) and I
Heard You (I-H-U) messages with that router. Computers
communicating via EGP are called EGP neighbors, and the
exchange of HELLO and I-H-U messages is referred to as
acquiring a neighbor.
Once the neighbor is acquired, the system polls the neighbor
for routing information. The neighbor responds by
sending an update containing routing information. If the
system receives a poll from its neighbor, it responds with
its own update packet. When the system receives an
update, it includes routes from the update into its routing
database. If the neighbor fails to respond to three
consecutive polls, gated assumes that the neighbor is down
and removes the neighbor's routes from its database.
EGP Syntax [Toc] [Back]
egp yes | no | on | off [ {
preference preference ;
defaultmetric metric ;
packetsize number ;
traceoptions trace_options ;
group
[peeras autonomous_system]
[localas autonomous_system]
[maxup number]
{
neighbor host
[preference preference]
[preference2 preference]
[metricout metric]
[nogendefault]
[importdefault]
[exportdefault]
[gateway gateway]
[lcladdr local_address]
[sourcenet network]
[minhello | p1 time]
[minpoll | p2 time]
[ttl ttl]
[traceoptions trace_options]
;
} ; } ] ;
Sets the preference for routes learned from RIP. The
default preference is 200. This preference can be overridden
by a preference specified on the group or neighbor
statements or by import policy. Defines the metric used
when advertising routes via EGP. If not specified, the
default value is 255, which some systems can consider
unreachable. This choice of values requires you to
explicitly specify a metric when exporting routes to EGP
neighbors. This metric can be overridden by a metric
specified on the neighbor or group statements or in export
policy. Defines the expected maximum size of a packet
that EGP expects to receive from this neighbor. If a
packet larger than this value is received, it is incomplete
and is discarded. The length of this packet is
noted and the expected size is increased to be able to
receive a packet of this size. Specifying the parameter
here prevents the first packet from being dropped. If not
specified, the default size is 8192 bytes. All packet
sizes are rounded up to a multiple of the system page
size. Specifies the tracing options for EGP. By default
these are inherited from the global trace options. These
values can be overridden on a group or neighbor basis.
(See the Trace Options Statement section in gated.conf(4)
and the EGP-specific tracing options that follow.) EGP
neighbors must be specified as members of a group. A
group is usually used to group all neighbors in one
autonomous system. Parameters specified on the group
clause apply to all of the subsidiary neighbors unless
explicitly overridden on a neighbor clause. Any number of
group clauses can specify any number of neighbor clauses.
Any parameters from the neighbor subclause can be
specified on the group clause to provide defaults
for the whole group (which can be overridden for
individual neighbors). In addition, the group
clause is the only place to set the following
attributes: Identifies the autonomous system number
expected from peers in the group. If not specified,
it is learned dynamically. Identifies the
autonomous system that gated is representing to the
group. The default is that which has been set
globally in the autonomoussystem statement. This
option is usually only used when masquerading as
another autonomous system and its use is discouraged.
Specifies the number of neighbors gated
should acquire from this group. The default is to
acquire all of the neighbors in the group. The
gated daemon attempts to acquire the first maxup
neighbors in the order listed. If one of the first
neighbors is not available, it acquires one farther
down the list. If after start-up gated does manage
to acquire the more desirable neighbor, it drops
the less desirable one. Each neighbor subclause
defines one EGP neighbor within a group. The only
part of the subclause that is required is the
neighbor_address argument, which is the symbolic
host name or IP address of the neighbor. The following
parameters are optional: Specifies the preference
used for routes learned from these neighbors.
This can differ from the default EGP preference
set in the egp statement, so that gated can
prefer routes from one neighbor, or group of neighbors,
over another. This preference can be explicitly
overriden by import policy. In the case of a
preference tie, the second preference, preference2,
can be used to break the tie. The default value is
0. Defines a metric to be used for all routes sent
to this neighbor. The value overrides the default
metric set in the egp statement and any metrics
specified by export policy, but only for this specific
neighbor or group of neighbors. Prevents
gated from generating a default route when EGP
receives a valid update from its neighbor. The
default route is generated only when the gendefault
option is enabled. Enables gated to accept the
default route (0.0.0.0) if it is included in a
received EGP update. If not specified, the default
route contained in an EGP update is ignored. For
efficiency, some networks have external routers
announce a default route to avoid sending large EGP
update packets. Enables gated to include the
default route (0.0.0.0) in EGP updates sent to this
EGP neighbor. This allows the system to advertise
the default route via EGP. Normally a default
route is not included in EGP updates. If a network
is not shared with a neighbor, gateway specifies a
router on an attached network to be used as the
next hop router for routes received from this
neighbor. This option is rarely used. Specifies
the address used on the local end of the connection
with the neighbor. The local address must be on an
interface that is shared with the neighbor or with
the neighbor's gateway when the gateway parameter
is used. A session is opened only when an interface
with the appropriate local address (through
which the neighbor or gateway address is directly
reachable) is operating. Specifies the network
queried in the EGP Poll packets. By default this
is the network shared with neighbors address specified.
If there is no network shared with the
neighbor, specify one of the networks to which the
neighbor is attached. You can also use this parameter
to specify a network shared with the neighbor
other than the one on which the EGP packets are
sent. This parameter is normally not needed. Sets
the minimum acceptable interval between the transmission
of EGP HELLO packets. The default hello
interval is 30 seconds. If the neighbor fails to
respond to three hello packets, gated stops trying
to acquire the neighbor. Setting a larger interval
gives the neighbor a better chance to respond. The
minhello parameter is an alias for the P1 value
defined in the EGP specification. Sets the time
interval between polls to the neighbor. The
default is 120 seconds. If three polls are sent
without a response, the neighbor is declared down
and all routes learned from that neighbor are
removed from the routing database. A longer
polling interval supports a more stable routing
database, but is not as responsive to routing
changes. The minpoll parameter is an alias for the
P2 value defined in the EGP specification. By
default, gated sets the IP TTL for local neighbors
to one and the TTL for non-local neighbors to 255.
This option is provided when attempting to communicate
with improperly functioning routers that
ignore packets sent with a TTL of one. Specifies
the tracing options for this EGP neighbor. By
default these are inherited from group or EGP
global trace options. (See the Trace Options
Statement section in gated.conf(4) and the EGP
tracing options that follow.)
EGP Tracing options [Toc] [Back]
The state and policy options work with EGP. The following
packet tracing options, which can be modified with detail,
send, and recv, are supported for the EGP protocol: Traces
all EGP packets Traces EGP HELLO/I-HEARD-U packets, which
are used to determine neighbor reachability. Traces EGP
ACQUIRE/CEASE packets, which are used to initiate and terminate
EGP sessions. Traces EGP POLL/UPDATE packets,
which are used to request and receive reachability
updates.
The BGP Protocol Statement [Toc] [Back] The Border Gateway Protocol (BGP) is an exterior routing
protocol used for exchanging routing information between
autonomous systems. BGP is used for exchange of routing
information between multiple transit autonomous systems as
well as between transit and stub autonomous systems. BGP
is related to EGP, but operates with more capability,
greater flexibility, and less required bandwidth.
BGP uses path attributes to provide more information about
each route, and in particular maintain an AS path, which
includes the AS number of each autonomous system the route
has transited, providing information sufficient to prevent
routing loops in an arbitrary topology. Path attributes
can also be used to distinguish between groups of routes
to determine administrative preferences, allowing greater
flexibility in determining route preference to achieve a
variety of administrative ends.
BGP supports two basic types of sessions between neighbours,
internal (sometimes referred to as IBGP) and external.
Internal sessions are run between routers in the
same autonomous system, while external sessions run
between routers in different autonomous systems. When
sending routes to an external peer the local AS number is
prepended to the AS path, hence routes received from an
external peer are guaranteed to have the AS number of that
peer at the s
|
