Read Problem: The customer has IGMP configured On in a Hewlett-Packard J4093A ProCurve Switch 2424M and found that the Switch was flooding ReadServer multicast IP traffic on all ports, in spite of the fact that clients had performed Joins text version

IP Multicast and IGMP:

Hewlett-Packard Procurve Switch 4108GL Default Behavior, Address

Mapping, and Reserved Addresses

This article applies to the following Hewlett-Packard Procurve Switch: 4108GL (J4865A) and 4108GL bundle (J4861A). The Switch 4108GL and 4108GL bundle implement IGMP version 2 and are compliant with RFC 2236. This tech note assumes that you have already read the IGMP chapter in the HP Procurve Switch 4108GL Management and Configuration Guide. For general information on the operation of IGMP, see the manual section How IGMP Operates. Sometimes, users configure IGMP on the 4108GL, but IP multicast pruning (that is, filtering or blocking) does not begin immediately. The following discussions explain some of those scenarios.

Default Behavior with respect to Pruning, Before Joins

The Switch 4108GL floods IP multicast packets unless it receives an indication that hosts are running IGMP (Internet Group Management Protocol). Once the switch receives a Join (IGMP Membership Report) for a particular multicast group, the switch will prune outgoing traffic for that group for all ports that did not receive a Join. The reason that the switch does not block all IP multicast traffic by default (that is, regardless of Joins) is that some applications use IP multicast addresses, but not IGMP. These applications rely on not having their traffic filtered (pruned) by switches. Users can limit the IP multicast traffic using either of the following alternatives: 1) Start up an IGMP client so that it will do a Join, thereby causing the switch to start filtering the IP multicast traffic; or 2) Do not start the IP multicast server until clients are ready to do Joins.

IP Multicast -> Ethernet Multicast Address Mapping

An IP multicast packet's destination IP address maps to, and therefore determines, the packet's Ethernet destination address. That is, IP multicast -> Ethernet Multicast. This mapping and some of its implications are complicated, however. The following discussion describes how packets with four different IP multicast addresses will be treated identically by the Switch 4108GL. RFC 2236 Internet Group Management Protocol, Version 2 specifies that IP multicast addresses are class D IP addresses. These addresses have 0xE hexadecimal, which is 1110 binary, in the high order four bits of the high order byte (see the blue bits in the diagram below). The next five bits after the 0xE (see the gray bits and the purple bit) are not mapped into the Ethernet address, so they are "don't care" bits. Per RFC 1112, the low-order 23 bits of the IP multicast address determine the low-order 23 bits of the Ethernet address (see the red bits in the diagram). RFC 1700 Assigned Numbers tells us that, for IP multicast packets, the upper 24 bits of the Ethernet address are always 0x01005E (see green bits). HP Procurve switches look for 0x01005E at the beginning of the destination MAC address in order to identify IP multicast packets that it should consider for pruning.

Four Example IP Multicast Addresses:

Decimal ------------224.138.18.52 226.10.18.52 228.10.18.52 239.138.18.52 Hexadecimal

------------(E0-8A-12-34)

(E2-0A-12-34)

(E4-0A-12-34)

(EF-8A-12-34)

Binary

--------------------------------------1110 0000 1000 1010 0001 0010 0011 0100

1110 0010 0000 1010 0001 0010 0011 0100

1110 0100 0000 1010 0001 0010 0011 0100

1110 1111 1000 1010 0001 0010 0011 0100

mapped IP Address

(hexadecimal)

Ethernet Address

| E v | 0/8 A | 1 2 | 3 4 | |____ ____|____ ____|____ ____|____ ____| |---- ----|---- ----|---- ----|---- ----| |1110 vvvv|v000 1010|0001 0010|0011 0100| |---------|---------|---------|---------| | Not ->|\_____ ________/ Mapped \____ ____/

\ /

|

|

/ \

_______/ \___________

/ \

|--------|--------|--------|--------|--------|--------|

|00000001|00000000|01011110|00001010|00010010|00110100|

|--------|--------|--------|--------|--------|--------|

|________|________|________|________|________|________|

| 0 1 | 0 0 | 5 E | 0 A | 1 2 | 3 4 |

Diagram footnote: A "v" means that the corresponding IP multicast bit varies, based on the specific IP multicast address. Note that the "v" bits do not map into the Ethernet address.

The example above shows how all addresses with 224 through 239 decimal in the first byte of the IP multicast address all map to the same Ethernet address. Note that the high order bit in the 2nd byte of the IP multicast address, namely bit 24 of the full address (see the bit in purple), does not map into the Ethernet address. Therefore, we cannot distinguish between 10 (0x0A) and 138 (0x8A) in the 2nd byte of the IP multicast address in the example above. In the Ethernet address, bit 24, the highorder bit of the second byte, is set to zero per the IANA (Internet Assigned Numbers Authority), and is reserved for other uses. This is specified in the Ether Types document at: http://www.iana.org/assignments/ethernet-numbers The four IP multicast addresses shown in the diagram above all map to the same Ethernet address, 0x01005E-0A1234. Why does this matter? The 4108GL's IGMP implementation looks at destination Ethernet addresses in order to recognize multicast IP traffic, so the switch treats the four IP multicast addresses above identically, with respect to pruning. Users must take care to choose IP multicast addresses that generate proper Ethernet addresses. That is, the Ethernet address must not conflict with the Ethernet address of other IP multicast addresses on the same network. Also, the Ethernet addresses must not conflict with reserved or in-use IP multicast addresses. This is discussed further in the next section.

Reserved and In-Use IP Multicast Addresses

Sometimes, users unintentionally configure an IP multicast address that is reserved or in use into their multicast server. As a result, the server's multicast traffic may be always forwarded (or never forwarded), regardless of the IGMP configuration, Joins, etc. There are generally two reasons that this happens: 1) the complexity (see the previous section) of the IP multicast address-toEthernet address mapping; or 2) conflict with reserved and in-use multicast addresses.

Reserved and in-use IP multicast addresses are handled specially by switches that implement IGMP. An understanding of these special addresses will help users avoid this problem. In-use addresses The Cisco router HSRP (Hot Standby Routing Protocol) uses the IP In-use addresses. multicast address range 238.0.0.0 through 238.0.0.255. Cisco routers do not issue IGMP packets (Joins, for example) to help switches determine where this multicast traffic should be forwarded. For this reason, the 4108GL always forwards packets in the HSRP address range. If the switch were to filter these packets, it would interfere with the Cisco HSRP protocol. As stated in the previous section, the 4108GL's IGMP implementation looks at destination Ethernet MAC addresses, not at the IP address, in order to recognize multicast IP traffic. And the IP multicast-to-Ethernet multicast address mapping illustrated in the previous section showed that the four IP multicast addresses, 224.138.18.52, 226.10.18.52, 228.10.18.52, and 239.138.18.52, all map to the same Ethernet address. So, because of the don't care bits in the IP multicast address, all of the addresses in table below map to Ethernet address 01005e-0a1234. These addresses all correspond to the HSRP IP multicast address range. The 4108GL also treats the X.128.0.X addresses as being equivalent to X.0.0.X, in case the setting of the IANA reserved bit (bit 24) changes. The 4108GL's handling of special addresses has not been documented correctly in all versions of the Procurve Switch 4108GL Management and Configuration Guide. Some versions of the guide state: Traffic to IP multicast groups in the IP range of 224.0.0.0 to 224.0.0.225 will always be flooded because addresses in this range are "well known" or "reserved" addresses. This statement is incomplete because the 4108GL never filters IP multicast packets which contain any of the following 32 IP multicast address ranges in the IP Destination field, where X is any value:

224.0.0.X, 225.0.0.X, 226.0.0.X, 227.0.0.X, 228.0.0.X, 229.0.0.X, 230.0.0.X, 231.0.0.X, 232.0.0.X, 233.0.0.X, 224.128.0.X, 225.128.0.X, 226.128.0.X, 227.128.0.X, 228.128.0.X, 229.128.0.X, 230.128.0.X, 231.128.0.X, 232.128.0.X, 233.128.0.X,

234.0.0.X, 235.0.0.X, 236.0.0.X, 237.0.0.X, 238.0.0.X, 239.0.0.X,

234.128.0.X, 235.128.0.X, 236.128.0.X, 237.128.0.X, 238.128.0.X, 239.128.0.X

Reserved Addresses Some IP multicast addresses are reserved. Some of these Addresses. addresses should never be forwarded by switches that implement IGMP. For details, see the Internet Multicast Addresses document at: http://www.iana.org/assignments/multicast-addresses This list is dynamic, so it is recommended that users do not rely on the reserved address information presented in network device manuals.

Recommended Addresses For Local Use

The IANA provides address range 239.252.0.0-239.255.255.255 for so-called SiteLocal Scopes. The IANA intends that users use these addresses within their enterprise network, but not on the Internet. To be safe, users should use a LAN analyzer to verify that their target addresses are not used by other applications.

Finding RFCs

To locate an RFC, search the web for: Connected: An Internet Encyclopedia

Finding HP Procurve Manuals

To locate an HP Procurve manual, go to www.hp.com/go/hpprocurve, select Technical Support, then Manuals.

10/04/2001

Information

Problem: The customer has IGMP configured On in a Hewlett-Packard J4093A ProCurve Switch 2424M and found that the Switch was flooding ReadServer multicast IP traffic on all ports, in spite of the fact that clients had performed Joins

5 pages

Report File (DMCA)

Our content is added by our users. We aim to remove reported files within 1 working day. Please use this link to notify us:

Report this file as copyright or inappropriate

1145850


You might also be interested in

BETA
Problem: The customer has IGMP configured On in a Hewlett-Packard J4093A ProCurve Switch 2424M and found that the Switch was flooding ReadServer multicast IP traffic on all ports, in spite of the fact that clients had performed Joins