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: Layer 2 switch clustering and SMLT
- Chapter 10: Layer 3 switch clustering and RSMLT
- Chapter 11: Layer 3 switch clustering and multicast SMLT
- Chapter 12: Spanning tree
- Chapter 13: Layer 3 network design
- Chapter 14: SPBM design guidelines
- Chapter 15: 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
- Split-subnet and multicast
- Protocol Independent Multicast-Sparse Mode guidelines
- Protocol Independent Multicast-Source Specific Multicast guidelines
- Multicast for multimedia
- Chapter 16: System and network stability and security
- Chapter 17: QoS design guidelines
- Chapter 18: Layer 1, 2, and 3 design examples
- Glossary
RADIUS authentication supports: WEB, CLI, or SNMP. You can configure a list of up to 10 RADIUS
servers for all three methods combined. If you configure six servers for SNMP, you can configure
four servers for the other methods.
You can use the RADIUS server as a proxy for stronger authentication (see the following figure),
such as:
• SecurID cards
• Kerberos
• other systems like Terminal Access Controller Access-Control System Plus (TACACS+)
Figure 78: RADIUS server as proxy for stronger authentication
You must configure each RADIUS client to contact the RADIUS server. When you configure a client
to work with a RADIUS server, complete the following configurations:
• Enable RADIUS.
• Provide the IP address of the RADIUS server.
• Ensure that the shared secret matches what is defined in the RADIUS server.
• Provide the attribute value.
• Provide the use-by value.
The use-by value can be CLI, SNMP, or IGMP, or EAPoL.
• Indicate the order of priority in which the RADIUS server is used. (Order is essential when
more than one RADIUS server exists in the network.)
• Specify the User Datagram Protocol (UDP) port that the client and server use during the
authentication process. The UDP port between the client and the server must have the same or
equal value. For example, if you configure the server with UDP 1812, the client must use the
same UDP port value.
Other customizable RADIUS parameters require careful planning and consideration, for example,
switch timeout and retry. Use the switch timeout to define the number of seconds before the
authentication request expires. Use the retry parameter to indicate the number of retries the server
accepts before sending an authentication request failure.
Avaya recommends that you use the default value in the attribute-identifier field. If you change the
default value, you must alter the dictionary on the RADIUS server with the new value. To configure
the RADIUS feature, you require Read-Write-All access to the switch.
For more information about RADIUS, see Security for Avaya Virtual Services Platform 4000 Series,
NN46251-601.
System and network stability and security
158 Network Design Reference for Avaya VSP 4000 Series June 2015
Comments on this document? infodev@avaya.com










