| Neale Ranns | dfd3954 | 2020-11-09 10:09:42 +0000 | [diff] [blame^] | 1 | .. _barnacles: |
| 2 | |
| 3 | Barnacles |
| 4 | --------- |
| 5 | |
| 6 | Features that are stuck on the side of the FIB. Those that directly use |
| 7 | the services that the FIB provides. |
| 8 | |
| 9 | In the section on FIB fundamentals it was mentioned that there is a |
| 10 | separation between what to match and how to forward. In an IP FIB what |
| 11 | to match is the packet's destination address against a table of IP |
| 12 | prefixes, and how to forward is described by a list of paths (the |
| 13 | **fib_path_list_t**). |
| 14 | |
| 15 | ACL Based Forwarding |
| 16 | ^^^^^^^^^^^^^^^^^^^^ |
| 17 | |
| 18 | ACL Based Forwarding (ABF) is also know as policy based routing |
| 19 | (PBR). In ABF what to match is described by an ACL. |
| 20 | |
| 21 | ABF uses two VPP services; ACL as a service, as provided by the ACL |
| 22 | plugin and FIB path-lists. It just glues them together. |
| 23 | |
| 24 | An ABF policy is the combination of an ACL with the forwarding |
| 25 | description of a FIB path-list. An ABF attachment is the association |
| 26 | of [an ordered set of] ABF policies to an interface. The attachment is |
| 27 | consulted on the ingress path of the IP DP (as an input |
| 28 | feature). If the ACL matches then the associated forwarding is |
| 29 | followed, if not, the packet continues along the DP. Simples. |
| 30 | |
| 31 | Layer 3 Cross Connect |
| 32 | ^^^^^^^^^^^^^^^^^^^^^ |
| 33 | |
| 34 | An L3 cross-connect (L3XC) matches all packets |
| 35 | that ingress the interface and then forwards using the supplied FIB |
| 36 | path-list. Naturally it runs as an input feature in the IP |
| 37 | path. Super simples. |
| 38 | |
| 39 | IP Punt |
| 40 | ^^^^^^^ |
| 41 | |
| 42 | Matches all IP packets that VPP has punted. Why they are punted is not |
| 43 | relevant. All IP punted packets are sent by VPP to the punt feature |
| 44 | arc. This feature 'matches' all packets that it receives and forwards |
| 45 | using the FIB path-list. |
| 46 | |
| 47 | |
| 48 | Unicast Reverse Path Forwarding |
| 49 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 50 | |
| 51 | Unicast Reverse Path Forwarding (uRPF) is the process of ensuring that |
| 52 | a packet has a conforming source address. It comes in two |
| 53 | flavours: |
| 54 | |
| 55 | - loose: The source address must be reachable, i.e. FIB must have a |
| 56 | route that will forward to the source address. The default route |
| 57 | counts as long as it does not drop. |
| 58 | - strict: The source address is reachable via the interface on which |
| 59 | the packet arrived, i.e. the FIB's route for the source address must |
| 60 | include the input interface as an output interface. |
| 61 | |
| 62 | The uRPF feature can run on either the input or output IP feature |
| 63 | arc. In both cases it serves as an anti-spoofing check, though the |
| 64 | semantics are slightly different. On the input arc it enforces that |
| 65 | peers on that link are only using source addresses that they should - |
| 66 | a network admin should employ at the access edge. On the output |
| 67 | arc it enforces that a packet is sourced from a prefix that belongs to |
| 68 | the network, i.e. that is has originated from within an SP's |
| 69 | network, a network admin could use at its peering points. |
| 70 | |
| 71 | To perform a uRPF check, the DP performs an IP FIB lookup on the |
| 72 | source address, this always results in a load-balance (LB) object. If |
| 73 | the LB has only 1 bucket and that bucket stacks on a drop DPO, then |
| 74 | both a loose and strict check will fail, otherwise a loose check |
| 75 | will pass. Each LB object has an associated uRPF list object. This |
| 76 | object holds the list of interfaces through which the prefix is |
| 77 | reachable. To pass the strict check, the input/output interface must |
| 78 | be in this list. |