docs/gettingstarted/developers/fib20/attachedexport.rst

   1 .. _attachedexport:
   2
   3 Attached Export
   4 ^^^^^^^^^^^^^^^^
   5
   6 Extranets make prefixes in VRF A also reachable from VRF B. VRF A is the export VRF,
   7 B the import. Consider this route in the export VRF;
   8
   9 .. code-block:: console
  10
  11    # ip route add table 2 1.1.1.0/24 via 10.10.10.0 GigabitEthernet0/8/0
  12
  13 there are two ways one might consider representing this route in the import VRF:
  14
  15 #. ip route add table 3 1.1.1.0/24 via 10.10.10.0 GigabitEthernet0/8/0
  16 #. ip route add table 3 1.1.1.0/24 via lookup-in-table 2
  17
  18 where option 2) is an example of a de-aggregate route where a second lookup is
  19 performed in table 2, the export VRF. Option 2) is clearly less efficient, since
  20 the cost of the second lookup is high. Option 1) is therefore preferred. However,
  21 connected and attached prefixes, and specifically the adj-fibs that they cover,
  22 require special attention. The control plane is aware of the connected and
  23 attached prefixes that are required to be exported, but it is unaware of the
  24 adj-fibs. It is therefore the responsibility of FIB to ensure that whenever an
  25 attached prefix is exported, so are the adj-fibs and local prefixes that it
  26 covers, and only the adj-fibs and locals, not any covered more specific
  27 (sourced e.g. by API). The imported FIB entries are sourced as *attached-export*
  28 this is a low priority source, so if those prefixes already exist in the import
  29 VRF, sourced by the API, then they will continue to forward with that information.
  30
  31 .. figure:: /_images/fib20fig6.png
  32
  33 Figure 6: Attached Export Class diagram.
  34
  35 Figure 6 shows the data structures used to perform attached export.
  36
  37 - *fib_import_t*. A representation of the need to import covered prefixes. An instance is associated with the FIB entry in the import VRF. The need to import prefixes is recognised when an attached route is added to a table that is different to the table of the interface to which it t is attached. The creation of a *fib_import_t* will trigger the creation of a *fib_export_t*.
  38 - *fib_export_t*. A representation of the need to export prefixes. An instance is associated with the attached entry in the export VRF. A *fib_export_t* can have many associated *fib_import_t* objects representing multiple VRFs into which the prefix is exported.
  39
  40 .. figure:: /_images/fib20fig6.png
  41
  42 Figure 7: Attached Export object diagram
  43
  44 Figure 7 shows an object instance diagram for the export of a connected from table
  45 1 to two other tables. The /32 adj-fib and local prefix in the export VRF are
  46 exported into the import VRFs, where they are sourced as *attached-export* and
  47 inherit the forwarding information from the exported entry. The attached prefix
  48 in the import VRF also performs cover tracking with the connected prefix in the
  49 export VRF so that it can react to updates to that prefix that will require the
  50 removal the imported covered prefixes.