6 The two principal differences between multicast and unicast forwarding
9 * there is no load-balancing among paths, there is only replication
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.
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).
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.
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.
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:
44 .. code-block:: console
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
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:
52 .. code-block:: console
54 $ ip mroute add 1.1.1.1 239.1.1.1 via GigEthernet0/0/2 Accept
56 A (\*,G) entry is added by not specifying a source address:
58 .. code-block:: console
60 $ ip mroute add 232.2.2.2 via GigEthernet0/0/2 Forward
62 A (\*,G/m) entry is added by not specifying a source address and giving
63 the group address a mask:
65 .. code-block:: console
67 $ ip mroute add 232.2.2.0/24 via GigEthernet0/0/2 Forward
69 Entries are deleted when all paths have been removed and all entry flags (see below) are also removed.
74 There are a set of flags associated only with an entry, see:
76 .. code-block:: console
78 $ show mfib route flags
80 only some of these are relevant over the API/CLI:
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
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.
91 flags on an entry can be changed with:
93 .. code-block:: console
95 $ ip mroute <PREFIX> <FLAG>
97 An alternative approach to the RPF check, that does check the
98 accepting path set, is to give the entry and RPF-ID:
100 .. code-block:: console
102 $ ip mroute <PREFIX> rpf-id X
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.