Specifying the destination

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 at ``Specifying the source (export_list)''.

• Exporting to EGP and BGP

     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; that is, they range from 0 to 65535 inclusive with 0 being the most attractive.

  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 support only the propagation of natural networks, so the host and default route filters are meaningless.

• 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.

  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 that 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 such as RIP is not sufficient. This is a safeguard to verify that the announcement is intended.

• Exporting to OSPF

     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 route, 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 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. 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.