| Neale Ranns | 995ff06 | 2018-12-06 08:36:55 -0800 | [diff] [blame] | 1 | .. _mfib: |
| 2 | |
| 3 | IP Multicast FIB |
| 4 | ---------------- |
| 5 | |
| 6 | Basics |
| 7 | ^^^^^^ |
| 8 | |
| 9 | An IP multicast FIB (mFIB) is a data-structure that holds entries that |
| 10 | represent a (S,G) or a (\*,G) multicast group. There is one IPv4 and |
| 11 | one IPv6 mFIB per IP table, i.e. each time the user calls 'ip[6] table |
| 12 | add X' an mFIB is created. |
| 13 | |
| 14 | |
| 15 | A path describes either where a packet is sent to or where a packet is |
| 16 | received from. mFIB entries maintain two sets of 'paths'; the |
| 17 | forwarding set and the accepting set. Each path in the forwarding set |
| 18 | will output a replica of a received packet. A received packet is only |
| 19 | accepted for forwarding if it ingresses on a path that matches in the |
| 20 | accepting set - this is the RPF check. |
| 21 | |
| 22 | |
| 23 | To add an entry to the default mFIB for the group (1.1.1.1, 239.1.1.1) |
| 24 | that will replicate packets to GigEthernet0/0/0 and GigEthernet0/0/1, do: |
| 25 | |
| 26 | .. code-block:: console |
| 27 | |
| 28 | $ ip mroute add 1.1.1.1 239.1.1.1 via GigEthernet0/0/0 Forward |
| 29 | $ ip mroute add 1.1.1.1 239.1.1.1 via GigEthernet0/0/1 Forward |
| 30 | |
| 31 | the flag 'Forward' passed with the path specifies this path to be part of the replication set. |
| 32 | To add a path from GigEthernet0/0/2 to the accepting (RPF) set do: |
| 33 | |
| 34 | .. code-block:: console |
| 35 | |
| 36 | $ ip mroute add 1.1.1.1 239.1.1.1 via GigEthernet0/0/2 Accept |
| 37 | |
| 38 | A (\*,G) entry is added by not specifying a source address: |
| 39 | |
| 40 | .. code-block:: console |
| 41 | |
| 42 | $ ip mroute add 232.2.2.2 via GigEthernet0/0/2 Forward |
| 43 | |
| 44 | A (\*,G/m) entry is added by not specifying a source address and giving |
| 45 | the group address a mask: |
| 46 | |
| 47 | .. code-block:: console |
| 48 | |
| 49 | $ ip mroute add 232.2.2.0/24 via GigEthernet0/0/2 Forward |
| 50 | |
| 51 | Entries are deleted when all paths have been removed and all entry flags (see below) are also removed. |
| 52 | |
| 53 | Advanced |
| 54 | ^^^^^^^^ |
| 55 | |
| 56 | There are a set of flags associated only with an entry, see: |
| 57 | |
| 58 | .. code-block:: console |
| 59 | |
| 60 | $ show mfib route flags |
| 61 | |
| 62 | only some of these are relevant over the API/CLI: |
| 63 | |
| 64 | #. Signal - packets that match this entry will generate an event that |
| 65 | is sent to the control plane (which can be retrieved via the signal |
| 66 | dump API) |
| 67 | #. Connected - indicates that the control plane should be informed of |
| 68 | connected sources (also retrieved via the signal dump API) |
| 69 | #. Accept-all-itf - the entry shall accept packets from all |
| 70 | interfaces, thus eliminating the RPF check |
| 71 | #. Drop - Drop all packet matching this entry. |
| 72 | |
| 73 | flags on an entry can be changed with: |
| 74 | |
| 75 | .. code-block:: console |
| 76 | |
| 77 | $ ip mroute <PREFIX> <FLAG> |
| 78 | |
| 79 | An alternative approach to the RPF check, that does check the |
| 80 | accepting path set, is to give the entry and RPF-ID: |
| 81 | |
| 82 | .. code-block:: console |
| 83 | |
| 84 | $ ip mroute <PREFIX> rpf-id X |
| 85 | |
| 86 | the RPF-ID is an attribute of a received packet's meta-data and is |
| 87 | added to the packet when it ingresses on a given entity such as an |
| 88 | MPLS-tunnel or a BIER table disposition entry. |