As mentioned above, the syntax of the export statement varies depending on the protocol it is being applied to. One thing that applies in all cases is the specification of a metric. All protocols define a default metric to be used for routes being exported, in most cases this can be overridden at several levels of the export statement.

The specification of the source of the routing information being exported (the export_list ) is described below.

Exporting to EGP and BGP

export proto bgp | egp as autonomous system restrict ; export proto bgp | egp as autonomous system [ aspath-opt ] [ metric metric ] { export_list ; } ;

Exportation to EGP and BGP is controlled by an autonomous system. The same policy is applied to all routers in the AS. EGP metrics range from 0 to 255 inclusive, with zero being the most attractive.

BGP metrics are 16 bit unsigned quantities; that is, they range from 0 to 65535 inclusive with 0 being the most attractive. While BGP version 4 actually supports 32 bit unsigned quantities, GATED does not yet support this. In BGP version 4, the metric is otherwise known as the Multi-Exit Discriminator, or MED.

In BGP, the aspath-opt option may be used to send the BGP community attribute. Any communities specified with the aspath-opt option are sent in addition to any received with the route or specified in the group statement.

If no export policy is specified, only routes to attached interfaces will be exported. If any policy is specified the defaults are overridden; it is necessary to explicitly specify everything that should be exported.

Note that EGP and BGP versions 2 and 3 only support the propagation of natural networks, so the host and default route filters are meaningless. BGP version 4 supports the propagation of any destination along with a contiguous network mask.

Exporting to RIP

export proto rip [ ( interface interface_list ) | (gateway gateway_list ) ] restrict ; export proto rip [ ( interface interface_list ) | (gateway gateway_list ) ] [ metric metric ] { export_list ; } ;

Exportation to RIP is controlled by any of protocol, interface or gateway. If more than one is specified, they are processed from most general (protocol) to most specific (gateway).

It is not possible to set metrics for exporting RIP routes into RIP. Attempts to do this are silently ignored.

If no export policy is specified, RIP and interface routes are exported into RIP. If any policy is specified, the defaults are overridden; it is necessary to explicitly specify everything that should be exported in the export_list .

When exporting routes from other protocols, it is important to specify a metric on the export statement or in the route filters. Unless this is done, the value specified in defaultmetric is used. If not specified, the defaultmetric value is 16 (unreachable). It is likely that this is not the desired result.

RIP version 1 assumes that all subnets of the shared network have the same subnet mask so they are only able to propagate subnets of that network. RIP version 2 removes that restriction and is capable of propagating all routes when not sending version 1 compatible updates.

To announce routes which specify a next hop of the loopback interface (that is, static and internally generated default routes) via RIP, it is necessary to specify the metric at some level in the export clause. Just setting a default metric for RIP is not sufficient. This is a safeguard to verify that the announcement is intended.

Exporting to OSPF

export proto osfpase [ type 1 | 2 ] [ tag ospf_tag ] restrict ; export proto osfpase [ type 1 | 2 ] [ tag ospf_tag ] [ metric metric ] { export_list ; } ;

It is not possible to create OSPF intra- or interarea routes by exporting routes from the GATED routing table into OSPF. It is only possible to export from the GATED routing table into OSPF ASE routes. It is also not possible to control the propagation of OSPF routes within the OSPF protocol.

There are two types of OSPF ASE routes, type 1 and type 2. The default type is specified by the defaults subclause of the ospf clause. This may be overridden by a specification on the export statement.

OSPF ASE routes also have the provision to carry a tag. This is an arbitrary 32 bit number that can be used on OSPF routers to filter routing information. The default tag specified by the OSPF defaults clause may be overridden by a tag specified on the export statement.

A.18.5 Specifying the Source

The export list specifies export based on the origin of a route and the syntax varies depending on the source.

Exporting BGP and EGP Routes

proto bgp | egp autonomoussystem autonomous_system restrict ; proto bgp | egp autonomoussystem autonomous_system [ metric metric ] { route_filter [ restrict | ( metric metric ) ] ; } ;

BGP and EGP routes may be specified as the source autonomous system. All routes may be exported by AS path.

Exporting RIP Routes

proto rip [ ( interface interface_list ) | (gateway gateway_list ) ] restrict ; proto rip [ ( interface interface_list ) | (gateway gateway_list ) ] [ metric metric ] { route_filter [ restrict | ( metric metric ) ] ; } ;

RIP routes may be exported by protocol, source interface, or source gateway.

Exporting OSPF Routes

proto ospf | ospfase restrict ; proto ospf | ospfase [ metric metric ] { route_filter [ restrict | ( metric metric ) ] ; } ;

Both OSPF, and OSPF ASE routes may be exported into other protocols.

Exporting Routes from Nonrouting Protocols

Non-routing with interface proto direct | static | kernel [ (interface interface_list ) ] restrict ; proto direct | static | kernel [ (interface interface_list ) ] [ metric metric ] { route_filter [ restrict | ( metric metric ) ] ; } ;

These protocols may be exported by protocol, or by the interface of the next hop. These protocols are:

• direct routes to directly attached interfaces.
• static static routes specified in a static clause.
• kernel on systems with the routing socket, routes learned from the routing socket are installed in the GATED routing table with a protocol of kernel. These routes may be exported by referencing this protocol. This is useful when it is desirable to have a script install routes with the ROUTE command and propagate them to other routing protocols.

Nonrouting by Protocol

proto default | aggregate restrict ; proto default | aggregate [ metric metric ] { route_filter [ restrict | ( metric metric ) ] ; } ;

These protocols can only be referenced by protocol.

• default refers to routes created by the gendefault option. It is recommended that route generation be used instead.
• aggregate refers to routes synthesized from other routes when the aggregate and generate statements are used. See Section A.18.6 for more information.

Exporting by AS Path

proto proto | all aspath aspath_regexp origin any | ( [ igp ] [egp ] [ incomplete ] ) restrict ; proto proto | all aspath aspath_regexp origin any | ( [ igp ] [egp ] [ incomplete ] ) [ metric metric ] { route_filter [ restrict | ( metric metric ) ] ; } ;

When BGP is configured, all routes are assigned an AS path when they are added to the routing table. For all interior routes, this AS path specifies IGP as the origin and no AS in the AS path; the current AS is added when the route is exported. For EGP routes, this AS path specifies EGP as the origin and the source AS as the AS path. For BGP routes, the AS path is stored as learned from BGP.

AS path regular expressions are described in Section A.18.2>

Exporting by Route Tag

proto proto | all tag tag restrict ; proto proto | all tag tag [ metric metric ] { route_filter [ restrict | ( metric metric ) ] ; } ;

Both OSPF and RIP version 2 currently support tags, all other protocols always have a tag of zero. The source of exported routes may be selected based on this tag. This is useful when routes are classified by tag when they are exported into a given routing protocol.

A.18.6 Route Aggregation

Route aggregation is a method of generating a more general route given the presence of a specific route. It is used, for example, at an autonomous system border to generate a route to a network to be advertised using EGP, if one or more subnets of that network have been learned using RIP. Older versions of GATED automatically performed this function, generating an aggregate route to a natural network (using the old Class A, B and C concept), if there is an interface to a subnet of that natural network. However, that was not always the correct thing to do, and, with the advent of classless interdomain routing it is even more frequently the wrong thing to do. Therefore, aggregation must be explicitly configured. No aggregation is performed unless explicitly requested in an aggregate statement.

Route aggregation is also used by regional and national networks to reduce the amount of routing information passed around. With careful allocation of network addresses to clients, regional networks can just announce one route to regional networks instead of hundreds.

Aggregate routes are not actually used for packet forwarding by the originator of the aggregate route; they are used only by the receiver, if it wishes. A router receiving a packet that does not match one of the component routes that led to the generation of an aggregate route is supposed to respond with an ICMP network unreachable message. This is to prevent packets for unknown component routes from following a default route into another network where they would be forwarded back to the border router, and around and around again and again, until their TTL expires. Sending an unreachable message for a missing piece of an aggregate is only possible on systems with support for reject routes.

A slight variation of aggregation is the generation of a route based on the existence of certain conditions. This is sometimes known as the route of last resort. This route inherits the next hops and AS path from the contributor specified with the lowest (most favorable) preference. The most common usage for this is to generate a default based on the presence of a route from a peer on a neighboring backbone.

A.18.6.1 Aggregation and Generation Syntax

The syntax of the aggregate and generation statements are as follows:

aggregate default | ( network [ ( mask mask ) | ( masklen number ) ] ) [ preference preference ] [ brief ] { proto [ all | direct | static | kernel | aggregate | proto ] [ ( as autonomous system ) | ( tag tag ) | ( aspath aspath_regexp ) ] restrict ; proto [ all | direct | static | kernel | aggregate | proto ] [ ( as autonomous system ) | ( tag tag ) | ( aspath aspath_regexp ) ] [ preference preference ] { route_filter [ restrict | ( preference preference ) ] ; } ; } ; generate dffault | ( network [ ( mask mask ) | ( masklen ) [ preference preference ] [ brief ] { proto [ all | direct | static | kernel | aggregate | proto ] [ ( as autonomous system ) | ( tag tag ) | ( aspath aspath_regexp ) ] restrict ; proto [ all | direct | static | kernel | aggregate | proto ] [ ( as autonomous system ) | ( tag tag ) | ( aspath aspath_regexp ) ] [ preference preference ] { route_filter [ restrict | ( preference preference ) ]; } ; } ;

Routes that match the route filters are called contributing routes. They are ordered according to the aggregation preference that applies to them. If there are more than one contributing routes with the same aggregating preference, the route's own preferences are used to order the routes. The preference of the aggregate route will be that of contributing route with the lowest aggregate preference.

• preference specifies the preference to assign to the resulting aggregate route. The default preference is 130.
• brief used to specify that the AS path should be truncated to the longest common AS path. The default is to build an AS path consisting of SETs and SEQUENCEs of all contributing AS paths.
• proto specifies, in addition to the special protocols listed, the contributing protocol may be chosen from among any of the ones supported (and currently configured into) GATED.
• as restricts selection of routes to those learned from the specified autonomous system.
• tag restricts selection of routes to those with the specified tag.
• aspath restricts selection of routes to those that match the specified AS path.
• restrict indicates that these routes are not to be considered as contributors of the specified aggregate. The specified protocol may be any of the protocols supported by GATED.

A route may only contribute to an aggregate route which is more general than itself; it must match the aggregate under its mask. Any given route may only contribute to one aggregate route, which will be the most specific configured, but an aggregate route may contribute to a more general aggregate.

Route Filters

All the formats allow route filters as shown below. See Section A.18.4.2 for a detailed explaination of how they work. When no route filtering is specified (that is, when restrict is specified on the first line of a statement), all routes from the specified source will match that statement. If any filters are specified, only routes that match the specified filters will be considered as contributors. That is, if any filters are specified, an all restrict ; statement is assumed at the end of the list.

network [exact | refines | between number and number ] network mask mask [exact | refines | between number and number ] network masklen number [ exact | refines | between number and number ] ] default host host

A.19 Sample Host Configurations

The configuration file for end systems is simple, usually containing only two configuration statements.

• The following sample configuration file emulates ROUTED. It runs RIP and only sends updates if there is more than one interface up and IP forwarding is enabled in the kernel:

  # rip yes ; #

  
  Note that RIP will not run if UDP checksums are disabled in the kernel.

• The following sample runs RIP in quiet mode; it only listens to packets, no matter how many interfaces are configured:

  # rip yes ; { nobroadcast ; } ; #

• The following sample is suitable for any system that runs RIP and has only one network interface:

  # # do not time-out the network interface # interface 136.66.12.2 passive ; # # enable rip # rip yes ; #

  
  The passive keyword prevents GATED from changing the preference of the route to this interface if it is believed to be down due to lack of received routing information. The interface passive statement identifies a router with a guest host on an Ethernet.
  In the example, the route is through the directly attached network interface. Normally, when GATED thinks an interface is down, it removes it from the routing database to prevent a gateway from announcing that it can route data through a nonoperational interface.
  If the host has only one interface, it should not be removed from the routing database even if the interface is down (the interface 136.66.12.2 passive statement in the example). RIP is enabled with the rip yes statement. This statement is not required because it is the default, but the explicit statement in the GATED.CONF file serves to document the configuration to prevent future confusion.

The following sample enables both an interior (RIP) and an exterior (EGP) protocol and sets certain protocol-specific parameters:

# generate a default route if an EGP neighbor is acquired # options gendefault ; # # define the autonomous system number for EGP # autonomoussystem 303 ; # # enable RIP # rip yes ; # # enable EGP with hello interval 1 1/2 minute, poll # interval 10 minutes, neighbors 26.6.0.103 and 26.20.0.72 # egp yes { packetsize 24488 ; group minhello 1:30 minpoll 10:00 { neighbor 26.6.0.103 ; neighbor 26.20.0.72 ; } ; } ; # # announce 136.66 to AS 183 # export proto egp as 183 { proto direct { 136.66 metric 0 ; } ; } ; # # announce default through RIP with a metric of 3 # export proto rip interface 136.66.12.1 { proto default { announce 0.0.0.0 metric 3 ; } ; } ;

The AS number 303 is defined early because it is a definition statement and must occur before the first protocol statement. EGP is enabled by the yes keyword in the EGP statement. This statement also defines the following EGP parameters:

• Packetsize parameter, which defines the initial size of update packets accepted.
• Group clause, which sets parameters for all of the EGP neighbors in the group.
• Minhello and minpoll , which set the protocol timers.

The first export statement directs GATED to use EGP to advertise the network (136.66.0.0) to the Internet. This is the address of the network, not of a gateway. The second export statement is used to announce the default route to subnet 136.66.12.0 with a metric of 3.

A.19.2 Sample BGP and OSPF Configuration

The following sample implements the transformation of distance metrics between the internal (OSPF) and external (BGP) protocols. Autonomous system 1019, of which GATED is a member, contains network 19.0.0.0. The GATED machine has several interfaces into this autonomous system. The GATED daemon is using BGP to peer with AS 2021, neighbor 21.5.1.21.

# # # # # # # # # # # # # # # # # # # interfaces {options all passive; }; autonomoussystem 1019; routerid 19.1.1.18; rip no; hello no; egp no; bgp yes { preference 50 ; group type External peeras 2021 { peer 21.5.1.21 ; } ; group type IGP peeras 1019 { peer 19.1.1.19 ; } ; } ; ospf yes { area 0.0.0.2 { authtype none; networks { 119.0.0.0 mask 255.0.0.0 ; } ; interface 119.2.128.18 cost 1 { retransmitinterval 5; transitdelay 1; priority 1; hello interval 10; routerdeadinterval 40; } ; interface 119.4.128.18 cost 1 { retransmitinterval 5; transitdelay 1; priority 1; hellointerval 60; routerdeadinterval 180; } ; } ; backbone { authype none; interface 19.1.1.19 cost 1 { retransmitinterval 5; transitdelay 1; priority 1; hellointerval 60; routerdeadinterval 180; } ; } ; } ; export proto ospfase type 1 { proto bgp as 2021 { ALL metric 1; }; proto direct { ALL metric 1; }; } ; export proto bgp as 2021 { proto direct { ALL metric 1; } ; proto ospfase { ALL metric 1; } ; } ;

In this example, two autonomous systems (one internal, one external) are directly connected through a router that is attached to a backbone speaking OSPF. The AS number 1019 is defined early, because it is a definition statement that occurs again in the first protocol statement, which enables BGP. The first export statement directs GATED to advertise routes from the internal group AS 1019. The group AS 1019 is running OSPF as its interior gateway protocol and is running BGP as its exterior routing protocol to route information to the external group AS 2021.

Routes to two local Ethernets in AS 1019, identified as 119.2.128.18 and 119.4.128.18 (119.0.0.0 mask 255.0.0.0), are advertised along with the OSPF backbone (19.1.1.19). The parameters for AS path, path origin, and transitive optional attributes, including transmission intervals, are defined. The second export statement announces the default route to AS 2021 with a metric of 1.