]>
Commit | Line | Data |
---|---|---|
12e41d03 DL |
1 | C1 IGMPv3 backward compatibility with IGMPv1 and IGMPv2 is not |
2 | implemented. See RFC 3376, 7.3. Multicast Router Behavior. That's | |
3 | because only Source-Specific Multicast is currently targeted. | |
4 | ||
5 | C2 IGMPv3 support for forwarding any-source groups is not | |
6 | implemented. Traffic for groups in mode EXCLUDE {empty} won't be | |
7 | forwarded. See RFC 3376, 6.3. Source-Specific Forwarding | |
8 | Rules. That's because only Source-Specific Multicast is currently | |
9 | targeted. | |
10 | ||
11 | C3 Load Splitting of IP Multicast Traffic over ECMP is not supported. | |
12 | See also: RFC 2991 | |
13 | Multipath Issues in Unicast and Multicast Next-Hop Selection | |
14 | http://www.rfc-editor.org/rfc/rfc2991.txt | |
15 | ||
16 | C4 IPSec AH authentication is not supported (RFC 4601: | |
17 | 6.3. Authentication Using IPsec). | |
18 | ||
19 | C5 PIM support is limited to SSM mode as defined in section 4.8.2 | |
20 | (PIM-SSM-Only Routers) of RFC4601. That's because only | |
21 | Source-Specific Multicast is currently targeted. | |
22 | ||
23 | C6 PIM implementation currently does not support IPv6. PIM-SSM | |
24 | requires IGMPv3 for IPv4 and MLDv2 for IPv6. MLDv2 is currently | |
25 | missing. See also CAVEAT C9. | |
26 | ||
27 | C7 FIXED (S,G) Assert state machine (RFC 4601, section 4.6.1) is not | |
28 | implemented. See also TODO T6. See also CAVEAT C10. | |
29 | ||
30 | C8 It is not possible to disable join suppression in order to | |
31 | explicitly track the join membership of individual downstream | |
32 | routers. | |
33 | - IGMPv3 Explicit Membership Tracking is not supported. | |
34 | When explicit tracking is enabled on a router, the router can | |
35 | individually track the Internet Group Management Protocol (IGMP) | |
36 | membership state of all reporting hosts. This feature allows the | |
37 | router to achieve minimal leave latencies when hosts leave a | |
38 | multicast group or channel. Example: | |
39 | conf t | |
40 | interface eth0 | |
41 | ip igmp explicit-tracking | |
42 | ||
43 | C9 Only IPv4 Address Family (number=1) is supported in the PIM Address | |
44 | Family field. | |
45 | See also RFC 4601: 5.1. PIM Address Family | |
46 | See also CAVEAT C6. | |
47 | See also http://www.iana.org/assignments/address-family-numbers | |
48 | ||
49 | C10 FIXED Assert metric depends on metric_preference and | |
50 | route_metric. Those parameters should be fetched from RIB | |
51 | (zebra). See also pim_rpf.c, pim_rpf_update(). | |
52 | ||
53 | C11 SSM Mapping is not supported | |
54 | ||
55 | SSM Mapping Overview: | |
56 | ||
57 | SSM mapping introduces a means for the last hop router to discover | |
58 | sources sending to groups. When SSM mapping is configured, if a | |
59 | router receives an IGMPv1 or IGMPv2 membership report for a | |
60 | particular group G, the router translates this report into one or | |
61 | more (S, G) channel memberships for the well-known sources | |
62 | associated with this group. | |
63 | ||
64 | When the router receives an IGMPv1 or IGMPv2 membership report for | |
65 | a group G, the router uses SSM mapping to determine one or more | |
66 | source IP addresses for the group G. SSM mapping then translates | |
67 | the membership report as an IGMPv3 report INCLUDE (G, [S1, G], | |
68 | [S2, G]...[Sn, G] and continues as if it had received an IGMPv3 | |
69 | report. The router then sends out PIM joins toward (S1, G) to (Sn, | |
70 | G) and continues to be joined to these groups as long as it | |
71 | continues to receive the IGMPv1 or IGMPv2 membership reports and | |
72 | as long as the SSM mapping for the group remains the same. SSM | |
73 | mapping, thus, enables you to leverage SSM for video delivery to | |
74 | legacy STBs that do not support IGMPv3 or for applications that do | |
75 | not take advantage of the IGMPv3 host stack. | |
76 | ||
77 | SSM mapping enables the last hop router to determine the source | |
78 | addresses either by a statically configured table on the router or | |
79 | by consulting a DNS server. When the statically configured table | |
80 | is changed, or when the DNS mapping changes, the router will leave | |
81 | the current sources associated with the joined groups. | |
82 | ||
83 | C12 FIXED MRIB for incongruent unicast/multicast topologies is not | |
84 | supported. RPF mechanism currently just looks up the information | |
85 | in the unicast routing table. | |
86 | ||
87 | See also: | |
88 | RFC5110: 2.2.3. Issue: Overlapping Unicast/Multicast Topology | |
89 | ||
90 | Sometimes, multicast RPF mechanisms first look up the multicast | |
91 | routing table, or M-RIB ("topology database") with a longest | |
92 | prefix match algorithm, and if they find any entry (including a | |
93 | default route), that is used; if no match is found, the unicast | |
94 | routing table is used instead. | |
95 | ||
96 | C13 Can't detect change of primary address before the actual change. | |
97 | Possible approach is to craft old interface address into ip source | |
98 | address by using raw ip socket. | |
99 | ||
100 | See also: | |
101 | ||
102 | RFC 4601: 4.3.1. Sending Hello Messages | |
103 | ||
104 | Before an interface goes down or changes primary IP address, a | |
105 | Hello message with a zero HoldTime should be sent immediately | |
106 | (with the old IP address if the IP address changed). | |
107 | ||
108 | See also pim_sock_delete(). | |
109 | ||
110 | C14 FIXED Detection of interface primary address changes may fail when | |
111 | there are multiple addresses. | |
112 | See also TODO T32. | |
113 | ||
114 | C15 Changes in interface secondary address list are not immediately | |
115 | detected. | |
116 | See also detect_secondary_address_change | |
117 | See also TODO T31. | |
118 | ||
119 | C16 AMT Draft (mboned-auto-multicast) is not supported. | |
120 | AMT = Automatic IP Multicast Without Explicit Tunnels | |
121 | ||
122 | See also: | |
123 | ||
124 | Draft | |
125 | http://tools.ietf.org/html/draft-ietf-mboned-auto-multicast | |
126 | http://tools.ietf.org/html/draft-ietf-mboned-auto-multicast-09 | |
127 | ||
128 | AMT gateway implementation for Linux | |
129 | http://cs.utdallas.edu/amt/ | |
130 | ||
131 | AMT for Streaming (IPTV) on Global IP Multicast by Greg Shepherd (Cisco) | |
132 | http://nznog.miniconf.org/nznog-2008-sysadmin-miniconf-greg-shepherd-iptv.pdf | |
133 | ||
134 | C17 SNMP / RFC 5060 (PIM MIB) is not supported. | |
135 | ||
136 | C18 MFC never recovers from removal of static route to source | |
137 | ||
138 | # route add -host 1.2.3.4 gw 192.168.56.10 | |
139 | Before removal: | |
140 | quagga-pimd-router# sh ip mroute | |
141 | Source Group Proto Input iVifI Output oVifI TTL Uptime | |
142 | 1.2.3.4 232.1.2.3 I eth1 3 eth0 2 1 00:00:36 | |
143 | ||
144 | # route del -host 1.2.3.4 gw 192.168.56.10 | |
145 | After removal: sh ip mroute --> empty output | |
146 | ||
147 | # route add -host 1.2.3.4 gw 192.168.56.10 | |
148 | After the route is restored: sh ip mroute --> never recovers (empty output) | |
149 | ||
150 | At this point, "no ip pim ssm" on the upstream interface (eth0) crashes pimd: | |
151 | ||
152 | 2014/02/14 16:30:14 PIM: ifmembership_set: (S,G)=(1.2.3.4,232.1.2.3) membership now is NOINFO on interface eth0 | |
153 | 2014/02/14 16:30:14 PIM: pim_ifchannel_update_assert_tracking_desired: AssertTrackingDesired(1.2.3.4,232.1.2.3,eth0) changed from 1 to 0 | |
154 | 2014/02/14 16:30:14 PIM: pim_zebra.c del_oif: nonexistent protocol mask 2 removed OIF eth0 (vif_index=2, min_ttl=0) from channel (S,G)=(1.2.3.4,232.1.2.3) | |
155 | 2014/02/14 16:30:14 PIM: pim_ifchannel_update_could_assert: CouldAssert(1.2.3.4,232.1.2.3,eth0) changed from 1 to 0 | |
156 | 2014/02/14 16:30:14 PIM: pim_ifchannel_update_my_assert_metric: my_assert_metric(1.2.3.4,232.1.2.3,eth0) changed from 0,0,0,10.0.2.15 to 1,4294967295,4294967295,0.0.0.0 | |
157 | 2014/02/14 16:30:14 PIM: pim_zebra.c del_oif: nonexistent protocol mask 1 removed OIF eth0 (vif_index=2, min_ttl=0) from channel (S,G)=(1.2.3.4,232.1.2.3) | |
158 | 2014/02/14 16:30:14 PIM: Assertion `!IGMP_SOURCE_TEST_FORWARDING(source->source_flags)' failed in file pim_igmpv3.c, line 412, function igmp_source_delete | |
159 | ||
160 | C19 Provision to prevent group mode clash | |
161 | ||
162 | Beware group mode clash. A host/application issuing IGMPv2 | |
163 | any-source joins for a group will disrupt SSM multicast for that | |
164 | group. | |
165 | ||
166 | For instance, support for source-specific static igmp WILL FAIL if | |
167 | there is host/application issuing IGMPv2 any-source joins for the | |
168 | same group. | |
169 | ||
170 | The reason is the IGMPv2 any-source join forces qpimd to switch | |
171 | the group mode to ASM (any-source multicast); however, qpimd is | |
172 | unable to program ASM groups into the kernel; multicast won't | |
173 | flow. There could be some provision to prevent such a behavior, | |
174 | but currently there is none. | |
175 | ||
176 | -x- |