The export statement controls which routes are advertised by GateD to other systems as well as what routes are redistributed between the protocols ran on the router. Like the import statement, the syntax of the export statement varies slightly per protocol. The syntax of the export statement is slightly different from the syntax of the import statement although 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. In other words, the import statement list a set of routes that a given protocol will accept from a given source. The export statement statement list a set of routes learned from a given source, that will be announced to a given destination. For instance you can configure BGP to announce to the peer on autonomous system AS123 all the routes learned from the RIP protocol. This is a case of inter protocol route redistribution.
Basically the outer portion of a given export statement specifies the destination of the routes you are exporting. The middle portion restricts the sources of the routes that you wish to consider. And the innermost portion is a route filter used to select individual routes.
Moreover a metric is set for any exported route. This metric is send to the peer by certain protocol and may be used by the peer to choose the better route to a given destination. The following section explains the detail syntax of the export for different protocols, as well as the use of the metric.
Some routing protocol can associate a metric to a route when announcing the route. The export statement accepts to optional keywords to specify the metric to be sent with the route or to disable the route announcement:
A route filter can be used with the export statement to explicitly list all the exported routes. All the formats allow route filters as shown below. See section 4.25.1 on route filters for a detailed explanation of how they work. When no route filtering is specified (i.e. 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 exported. Put differently, if any filters are specified, an ' all restrict ;' is assumed at the end of the list.
network [ exact | refines ]
network mask mask [ exact | refines ]
network masklen number [ exact | refines ]
default
host host
export proto bgp | egp as autonomous system
restrict ;
export proto bgp | egp as autonomous system
[ 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.
The export_list specifies the source of the route we want to export. The syntax of this export_list depend of the source protocol, and is explained in section 4.27.7.
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 exports.
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.
The export_list specifies the source of the route we want to export. The syntax of this export_list depend of the source protocol, and is explained in section 4.27.7.
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 exports.
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 loop back 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 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 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 configuration for a detailed explanation of the two types. The default type is specified by the defaults sub-clause 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. See the OSPF protocol configuration for detailed information on OSPF tags. The default tag specified by the ospf defaults clause may be overridden by a tag specified on the export statement.
The export_list specifies the source of the routes we want to export. The syntax of this export_list depend of the source protocol, and is explained in section 4.27.7.
The export_list used in the previous description of the export statement specifies the source of a set of routes based on parameter like the protocol from where the source as been learn. Indirectly the export_list controls the redistribution of routes between protocols. The syntax varies slightly per source protocol.
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 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</a> [ 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 ASes 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.
The example will concern the export of routes to a BGP peer. We want to announce to the BGP peer on autonomous system AS123 the following routing information:
The configuration file will look like:
# This control the BGP exports to the on autonomous system AS123
export proto bgp as AS123 {
# The BGP route learned from AS999
proto bgp as AS999 { all; };
# The static default route
proto static { default; };
# A certain set of our RIP routes
proto rip {
1.2.3 masklen 24;
1.2.4 masklen 24;
192.1.0;
};
};
More examples are provided in section 4.29.