89 lines
2.7 KiB
ReStructuredText
89 lines
2.7 KiB
ReStructuredText
|
.. _mfib:
|
||
|
|
||
|
IP Multicast FIB
|
||
|
----------------
|
||
|
|
||
|
Basics
|
||
|
^^^^^^
|
||
|
|
||
|
An IP multicast FIB (mFIB) is a data-structure that holds entries that
|
||
|
represent a (S,G) or a (\*,G) multicast group. There is one IPv4 and
|
||
|
one IPv6 mFIB per IP table, i.e. each time the user calls 'ip[6] table
|
||
|
add X' an mFIB is created.
|
||
|
|
||
|
|
||
|
A path describes either where a packet is sent to or where a packet is
|
||
|
received from. mFIB entries maintain two sets of 'paths'; the
|
||
|
forwarding set and the accepting set. Each path in the forwarding set
|
||
|
will output a replica of a received packet. A received packet is only
|
||
|
accepted for forwarding if it ingresses on a path that matches in the
|
||
|
accepting set - this is the RPF check.
|
||
|
|
||
|
|
||
|
To add an entry to the default mFIB for the group (1.1.1.1, 239.1.1.1)
|
||
|
that will replicate packets to GigEthernet0/0/0 and GigEthernet0/0/1, do:
|
||
|
|
||
|
.. code-block:: console
|
||
|
|
||
|
$ ip mroute add 1.1.1.1 239.1.1.1 via GigEthernet0/0/0 Forward
|
||
|
$ ip mroute add 1.1.1.1 239.1.1.1 via GigEthernet0/0/1 Forward
|
||
|
|
||
|
the flag 'Forward' passed with the path specifies this path to be part of the replication set.
|
||
|
To add a path from GigEthernet0/0/2 to the accepting (RPF) set do:
|
||
|
|
||
|
.. code-block:: console
|
||
|
|
||
|
$ ip mroute add 1.1.1.1 239.1.1.1 via GigEthernet0/0/2 Accept
|
||
|
|
||
|
A (\*,G) entry is added by not specifying a source address:
|
||
|
|
||
|
.. code-block:: console
|
||
|
|
||
|
$ ip mroute add 232.2.2.2 via GigEthernet0/0/2 Forward
|
||
|
|
||
|
A (\*,G/m) entry is added by not specifying a source address and giving
|
||
|
the group address a mask:
|
||
|
|
||
|
.. code-block:: console
|
||
|
|
||
|
$ ip mroute add 232.2.2.0/24 via GigEthernet0/0/2 Forward
|
||
|
|
||
|
Entries are deleted when all paths have been removed and all entry flags (see below) are also removed.
|
||
|
|
||
|
Advanced
|
||
|
^^^^^^^^
|
||
|
|
||
|
There are a set of flags associated only with an entry, see:
|
||
|
|
||
|
.. code-block:: console
|
||
|
|
||
|
$ show mfib route flags
|
||
|
|
||
|
only some of these are relevant over the API/CLI:
|
||
|
|
||
|
#. Signal - packets that match this entry will generate an event that
|
||
|
is sent to the control plane (which can be retrieved via the signal
|
||
|
dump API)
|
||
|
#. Connected - indicates that the control plane should be informed of
|
||
|
connected sources (also retrieved via the signal dump API)
|
||
|
#. Accept-all-itf - the entry shall accept packets from all
|
||
|
interfaces, thus eliminating the RPF check
|
||
|
#. Drop - Drop all packet matching this entry.
|
||
|
|
||
|
flags on an entry can be changed with:
|
||
|
|
||
|
.. code-block:: console
|
||
|
|
||
|
$ ip mroute <PREFIX> <FLAG>
|
||
|
|
||
|
An alternative approach to the RPF check, that does check the
|
||
|
accepting path set, is to give the entry and RPF-ID:
|
||
|
|
||
|
.. code-block:: console
|
||
|
|
||
|
$ ip mroute <PREFIX> rpf-id X
|
||
|
|
||
|
the RPF-ID is an attribute of a received packet's meta-data and is
|
||
|
added to the packet when it ingresses on a given entity such as an
|
||
|
MPLS-tunnel or a BIER table disposition entry.
|