Design Reference
Table Of Contents
- Contents
- Chapter 1: Introduction
- Chapter 2: New in this release
- Chapter 3: Network design fundamentals
- Chapter 4: Hardware fundamentals and guidelines
- Chapter 5: Optical routing design
- Chapter 6: Platform redundancy
- Chapter 7: Link redundancy
- Chapter 8: Layer 2 loop prevention
- Chapter 9: Spanning tree
- Chapter 10: Layer 3 network design
- Chapter 11: SPBM design guidelines
- Chapter 12: IP multicast network design
- Multicast and VRF-lite
- Multicast and MultiLink Trunking considerations
- Multicast scalability design rules
- IP multicast address range restrictions
- Multicast MAC address mapping considerations
- Dynamic multicast configuration changes
- IGMPv3 backward compatibility
- IGMP Layer 2 Querier
- TTL in IP multicast packets
- Multicast MAC filtering
- Guidelines for multicast access policies
- Multicast for multimedia
- Chapter 13: System and network stability and security
- Chapter 14: QoS design guidelines
- Chapter 15: Layer 1, 2, and 3 design examples
- Chapter 16: Software scaling capabilities
- Chapter 17: Supported standards, RFCs, and MIBs
- Glossary
In a network that includes non Virtual Services Platform 4000 equipment, the easiest way to
ensure that this issue does not arise is to use only a consecutive range of IP multicast
addresses that correspond to the lower order 23 bits of that range. For example, use an
address range from 239.0.0.0 through 239.127.255.255. A group address range of this size
can still easily accommodate the needs of even the largest private enterprise.
Dynamic multicast configuration changes
Avaya recommends that you do not perform dynamic multicast configuration changes when
multicast streams flow in a network. For example, do not change the routing protocol that runs
on an interface, or the IP address, or the subnet mask for an interface until multicast traffic
ceases.
For such changes, Avaya recommends that you temporarily stop all multicast traffic. If the
changes are necessary and you have no control over the applications that send multicast data,
you can disable the multicast routing protocols before you perform the change. For example,
consider disabling multicast routing before making interface address changes. In all cases,
these changes result in traffic interruptions because they impact neighbor state machines and
stream state machines.
In addition, Avaya recommends that when removing port members of an MLT group that you
first disable the ports before removing them from that MLT group. Changing the group set
without first shutting the ports down can result in high CPU utilization and processing in a scaled
multicast environment due to the necessary hardware reprogramming on the multicast
records.
IGMPv3 backward compatibility
IGMPv3 for PIM is backward compatible with IGMPv1/v2. According to RFC3376, the multicast
router with IGMPv3 can use one of two methods to handle older query messages:
• If an older version of IGMP is present on the router, the querier must use the lowest
version of IGMP present on the network.
• If a router that is not explicitly configured to use IGMPv1 or IGMPv2, hears an IGMPv1
query or IGMPv2 general query, it logs a rate-limited warning.
You can configure the IGMP version of an interface to version 3 regardless of the PIM or
snooping mode.
You can configure whether the switch downgrades the version of IGMP to handle older query
messages. If the switch downgrades, the host with IGMPv3 only capability does not work. If
you do not configure the switch to downgrade the version of IGMP, the switch logs a
warning.
IP multicast network design
112 Network Design Reference for Avaya VSP 4000 February 2014
Comments? infodev@avaya.com