docs/gettingstarted/developers/fib20/multicast.rst

   1 .. _mfib:
   2
   3 IP Multicast FIB
   4 ----------------
   5
   6 The two principal differences between multicast and unicast forwarding
   7 are:
   8
   9 * there is no load-balancing among paths, there is only replication
  10   across paths.
  11 * multicast forwarding has an explicit reverse path forwarding (RPF)
  12   check. It will only forward a packet if it arrives from a peer for
  13   which it has been explicitly configured to accept.
  14
  15 The other factor that influences the design of the mFIB is that the
  16 match criteria (the prefix) is different. For multicast it is
  17 necessary to be able to match on source and destination/group
  18 addresses (termed an (S,G)) and only on a destination prefix (a (\*,
  19 G/m)). This prefix is much bigger than a unicast prefix, and since
  20 unicast scale is almost always greater than multicast scale, it is not
  21 a good idea to have a single definition of a prefix. Therefore,
  22 there is a fib_prefix_t (and hence a fib_entry_t) and an
  23 mfib_prefix_t (and hence a mfib_entry_t).
  24
  25 The fib_path_t and fib_path_list_t are reused. A path can represent
  26 either a peer from which to accept packets or a peer to which to send
  27 packets. A path-extension is added to the fib_path_t/mfib_entry_t to
  28 describe the role the path plays. Logically the path-list is split
  29 into two sets; an accepting set and a forwarding set. The forwarding set
  30 contributes a replicate DPO for forwarding and the accepting set
  31 contributes a list of interfaces (an mfib_itf_t) for the RPF check.
  32
  33 An IP multicast FIB (mFIB) is a data-structure that holds entries that
  34 represent a (S,G) or a (\*,G/m) multicast group. There is one IPv4 and
  35 one IPv6 mFIB per IP table, i.e. each time the user calls 'ip[6] table
  36 add X' an mFIB is created.
  37
  38 Usage
  39 ^^^^^
  40
  41 To add an entry to the default mFIB for the group (1.1.1.1, 239.1.1.1)
  42 that will replicate packets to GigEthernet0/0/0 and GigEthernet0/0/1, do:
  43
  44 .. code-block:: console
  45
  46    $ ip mroute add 1.1.1.1 239.1.1.1 via GigEthernet0/0/0 Forward
  47    $ ip mroute add 1.1.1.1 239.1.1.1 via GigEthernet0/0/1 Forward
  48
  49 the flag 'Forward' passed with the path specifies this path to be part of the replication set.
  50 To add a path from GigEthernet0/0/2 to the accepting (RPF) set do:
  51
  52 .. code-block:: console
  53
  54    $ ip mroute add 1.1.1.1 239.1.1.1 via GigEthernet0/0/2 Accept
  55
  56 A (\*,G) entry is added by not specifying a source address:
  57
  58 .. code-block:: console
  59
  60    $ ip mroute add 232.2.2.2 via GigEthernet0/0/2 Forward
  61
  62 A (\*,G/m) entry is added by not specifying a source address and giving
  63 the group address a mask:
  64
  65 .. code-block:: console
  66
  67    $ ip mroute add 232.2.2.0/24 via GigEthernet0/0/2 Forward
  68
  69 Entries are deleted when all paths have been removed and all entry flags (see below) are also removed.
  70
  71 Advanced
  72 ^^^^^^^^
  73
  74 There are a set of flags associated only with an entry, see:
  75
  76 .. code-block:: console
  77
  78    $ show mfib route flags
  79
  80 only some of these are relevant over the API/CLI:
  81
  82 #. Signal - packets that match this entry will generate an event that
  83    is sent to the control plane (which can be retrieved via the signal
  84    dump API)
  85 #. Connected - indicates that the control plane should be informed of
  86    connected sources (also retrieved via the signal dump API)
  87 #. Accept-all-itf - the entry shall accept packets from all
  88    interfaces, thus eliminating the RPF check
  89 #. Drop - Drop all packet matching this entry.
  90
  91 flags on an entry can be changed with:
  92
  93 .. code-block:: console
  94
  95    $ ip mroute <PREFIX> <FLAG>
  96
  97 An alternative approach to the RPF check, that does check the
  98 accepting path set, is to give the entry and RPF-ID:
  99
 100 .. code-block:: console
 101
 102    $ ip mroute <PREFIX> rpf-id X
 103
 104 the RPF-ID is an attribute of a received packet's meta-data and is
 105 added to the packet when it ingresses on a given entity such as an
 106 MPLS-tunnel or a BIER table disposition entry.