The import statement controls which routes received from other systems are used by GateD, and the export statement controls which routes are advertised by GateD to other systems. Like the importstatement, the syntax of the export statement varies slightly per protocol. The syntax of the export statement is similar to the syntax of the import statement, and the meanings of many of the parameters are identical. The main difference between the two is that while route importation is just controlled by source information, route exportation is controlled by both destination and source.
The outer portion of a given export statement specifies the destination of the routing information you are controlling. The middle portion restricts the sources of importation that you wish to consider. And the innermost portion is a route filter used to select individual routes.
The most specific specification of a metric is the one applied to the route being exported. The values that may be specified for a metric depend on the destination protocol that is referenced by this export statement.
restrict metric metric
All the formats allow route filters as shown below. See the section on route filters for a detailed explanation of how they work. When no route filtering is specified (i.e. when restrictis 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 exported. Put differently, if any filters are specified, an all restrict ; 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
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.
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 autonomous system, the same policy is applied to all routers in the AS. EGP metrics range from 0 to 255 inclusive with 0 being the most attractive.
BGP metrics are 16-bit unsigned quantities, i.e. 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.
export proto rip | hello [ ( interface interface_list ) | (gateway gateway_list ) ] restrict ; export proto rip | hello [ ( interface interface_list ) | (gateway gateway_list ) ] [ metric metric ] { export_list ; } ;
Exportation to RIP and HELLO 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, or exporting HELLO routes into HELLO. Attempts to do this are silently ignored.
If no export policy is specified, RIP and interface routes are exported into RIP and HELLO and interface routes are exported into HELLO. If any policy is specified, the defaults are overridden; it is necessary to explicitly specify everything that should be exported.
RIP version 1 and HELLO assume 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 (i.e. static and internally generated default routes) via RIP or HELLO, it is necessary to specify the metric at some level in the export clause. Just setting a default metric for e.g. RIP or HELLO is not sufficient. This is a safeguard to verify that the announcement is intended.
export proto ospfase [ type 1 | 2 ] [ tag ospf_tag ] restrict ; export proto ospfase [ type 1 | 2 ] [ tag ospf_tag ] [ metric metric ] { export_list ; } ;
It is not possible to create OSPF intra- or inter-area 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, see the OSPF protocol configurationfor a detailed explanation of the two types. The default type is specified by the defaultssubclause of the ospf clause. This may be overridden by a specification on the exportstatement.
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. See the OSPF protocol configurationfor detailed information on OSPF tags. The default tag specified by the ospfdefaults clause may be overridden by a tag specified on the export statement.
The export list specifies export based on the origin of a route and the syntax varies depending on the source.
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 by source autonomous system. All routes may be exported by an AS path, see below for more information.
proto rip | hello [ ( interface interface_list ) | (gateway gateway_list ) ] restrict ; proto rip | hello [ ( interface interface_list ) | (gateway gateway_list ) ] [ metric metric ] { route_filter [ restrict | ( metric metric ) ] ; } ;
RIP and HELLO routes may be exported by protocol, source interface, and/or source gateway.
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. See below for information on exporting by tag.
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:
proto default | aggregate restrict ; proto default | aggregate [ metric metric ] { route_filter [ restrict | ( metric metric ) ] ; } ;
These protocols may only be referenced by protocol.
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 ASs 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 documented in the section on Matching AS paths.
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 the are exported into a given routing protocol.
Last updated November 30, 1997.
gated@gated.merit.edu