Network Design Reference for Avaya Virtual Services Platform 4000 Release 3.1 NN46251-200 Issue 01.
© 2014 Avaya Inc. All Rights Reserved. Notice While reasonable efforts have been made to ensure that the information in this document is complete and accurate at the time of printing, Avaya assumes no liability for any errors. Avaya reserves the right to make changes and corrections to the information in this document without the obligation to notify any person or organization of such changes.
corporate employee, agent, subcontractor, or is not working on your company's behalf). Be aware that there can be a risk of Toll Fraud associated with your system and that, if Toll Fraud occurs, it can result in substantial additional charges for your telecommunications services.
Network Design Reference for Avaya VSP 4000 Comments? infodev@avaya.
Contents Chapter 1: Introduction...................................................................................................... 9 Purpose..................................................................................................................................................... 9 Related resources..................................................................................................................................... 9 Documentation..................................................
VRF Lite.................................................................................................................................................... 55 Virtual Router Redundancy Protocol......................................................................................................... 57 Open Shortest Path First........................................................................................................................... 62 Border Gateway Protocol...................................
Quality of service....................................................................................................................................... 149 Network management............................................................................................................................... 150 MIBs.......................................................................................................................................................... 151 Standard MIBs............................
Network Design Reference for Avaya VSP 4000 February 2014
Chapter 1: Introduction Purpose This document provides information to help you build robust, efficient networks using the VSP 4000 platform. You can use the examples and important design guidelines listed in this document for many features and protocols. Related resources Documentation See the Avaya Virtual Services Platform 4000 Documentation Roadmap, NN46251–100 for a list of the documentation for this product. Training Ongoing product training is available.
Introduction Avaya Mentor videos Avaya Mentor videos provide technical content on how to install, configure, and troubleshoot Avaya products. About this task Videos are available on the Avaya Support website, listed under the video document type, and on the Avaya-run channel on YouTube. • To find videos on the Avaya Support website, go to http://support.avaya.com, select the product name, and check the videos checkbox to see a list of available videos.
Support all occurrences of a particular feature. Use this procedure to perform an index search of your documentation collection. Before you begin • Download the documentation collection zip file to your local computer. • You must have Adobe Acrobat or Adobe Reader installed on your computer. Procedure 1. Extract the document collection zip file into a folder. 2. Navigate to the folder that contains the extracted files and open the file named .pdx. 3.
Introduction 12 Network Design Reference for Avaya VSP 4000 Comments? infodev@avaya.
Chapter 2: New in this release The following sections detail what is new in the Network Design Reference for Avaya Virtual Services Platform 4000 (NN46251–200), for release 3.1. Features See the following sections for information on feature-related changes. IP multicast over SPBM In Release 3.1, Virtual Services Platform 4000 supports IP multicast over Shortest Path Bridging MAC (SPBM).
New in this release In Release 3.1, CFM also extends the debugging of Layer 2 networks to Customer VLANs (CVLANs). • For SPBM B-VLANs, you can use either autogenerated or explicitly-configured CFM MEPs. • For C-VLANs, you can only use autogenerated CFM MEPs. Important: Previous explicit CFM configurations of MDs, MAs, and MEPs on SPBM B-VLANs continue to function in this release.
Features Layer 2 tracemroute Release 3.1 adds the l2tracemroute command to trace the multicast tree for a given multicast flow. Transparent UNI Release 3.1 support Transparent UNI feature. A Transparent UNI (T-UNI) maps an entire port or MLT to an I-SID. On Transparent UNI, ISID untagged and tagged(802.1q) packets are Layer 2–switched and the forwarding decision is based only on the MAC Addresses; VLAN ID is not used. You can map multiple ports to a T-UNI I-SID.
New in this release Other changes There are no other changes to this document for release 3.1. 16 Network Design Reference for Avaya VSP 4000 Comments? infodev@avaya.
Chapter 3: Network design fundamentals To efficiently and cost-effectively use Avaya Virtual Services Platform 4000, you must properly design your network. Use the information in this section to help you properly design the network. To design networks, you must consider • reliability and availability • platform redundancy • desired level of redundancy A robust network depends on the interaction between system hardware and software.
Network design fundamentals Based on network problem-tracking statistics, the following list is an approximate stability estimation model of a system that uses these components: • Hardware and drivers represent a small portion of network problems. • Local software represents a more significant share. • Interacting software represents the vast majority of the reported issues.
Chapter 4: Hardware fundamentals and guidelines This section provides general hardware guidelines to use this product in a network. Use the information in this section to help you during the hardware design and planning phase. Platform considerations This section provides VSP 4000 platform power and cooling considerations. You must properly power and cool your device, or nonoptimal operation can result.
Hardware fundamentals and guidelines *Note: The seventh character (?) of the switch order number must be replaced with the proper letter to indicate desired product nationalization. See the following for details: “A”: No power cord included. “B”: Includes European “Schuko” power cord common in Austria, Belgium, Finland, France, Germany, The Netherlands, Norway, and Sweden. “C”: Includes power cord commonly used in the United Kingdom and Ireland. “D”: Includes power cord commonly used in Japan.
Platform considerations 4850GTS 4850GTS-PWR+ Power Consumption: 94.6W maximum 248W maximum Thermal Rating: 323 BTU/Hr maximum 508 BTU/Hr maximum Inrush Current: 40A maximum 70A maximum Turn on Condition: 1 second maximum after application of AC power 1 second maximum after application of AC power Important: 12 V output rise time, from 10 to 90 percent, must be the maximum of 50 ms and monotonic under all defined input and output conditions.
Hardware fundamentals and guidelines Figure 3: 300W power supply The 300W and 1000W AC power supplies use an IEC 60320 C16 AC power cord connector. The AC power cord is in close proximity to the hot air exhaust, and supports high operating temperatures Figure 4: IEC 60320 C16 connector Power over Ethernet Plus specifications Model Maximum PoE+ W Avaya VSP 4850GTS— PWR+ models 855W with one power supply 15.4W (802.3af) 1855W with two power 17.8W (802.3.at) — 1 power supplies supply 32.4W (802.
Hardware compatibility Avaya DC power supply The following table describes the DC power supply specifications for the Avaya Virtual Services Platform 4000. Table 3: DC power supply specifications Order Number AL1905005-E5 Description DC-DC-12V-300W Output power 300W Input voltage 48V DC Input current 10A Output voltage 12V DC Output current 25A Hardware compatibility The following tables describe the Avaya Virtual Services Platform 4000 hardware.
Hardware fundamentals and guidelines VSP 4000 model VSP 4850GTS-PWR+ Description Part number • Same content as EC4800A78-E6 with a NA power cord. EC4800E78-E6 • Same content as EC4800A78-E6 with a EU power cord. EC4800F78-E6 • 48 10/100/1000 802.3at PoE+ EC4800A88-E6 • two SFP ports • two SFP+ ports • Base Software License • one field replaceable 1000W PSU • Same content as EC4800A88-E6 with a EU power cord. EC4800B88-E6 • Same content as EC4800A88-E6 with a UK power cord.
Supported optical devices Caution: Avaya recommends that you use Avaya branded SFP and SFP+ transceivers as they undergo extensive qualification and testing. Avaya is not responsible for any problems that arise from using non-Avaya branded SFP and SFP+ transceivers.
Hardware fundamentals and guidelines Hardware Description Part number 1000BASE-ZX CWDM (LC) 1470 nm to 1610 nm Range up to 70 km AA1419061-E6 to AA1419068-E6 1000BASE-BX10 DDI SFP 1310 nm, single fiber LC Range up to 10 km AA1419069-E6 1000BASE-BX10 DDI SFP 1490 nm, single fiber LC Range up to 10 km AA1419070-E6 1000BASE-EX DDI SFP 1550 nm Range up to 120 km AA1419071-E6 1000BASE-BX40 bidirectional SFP 1310 nm, single fiber LC Range up to 40 km AA1419076–E6 1000BASE-BX40 bidirectional SFP
Dispersion considerations for long reach attenuation requirement based on the specifications of third-party equipment. For more information about minimum insertion losses for Avaya optical products, see Installing Transceivers and Optical components on the Avaya Virtual Services Platform 4000, NN46251-301.
Hardware fundamentals and guidelines the power budget is exceeded or margin is insufficient, you can either use a transceiver rated for longer distance operation, or calculate budget and losses using actual values rather than specified limit values. Either method can improve link budget by 4 to 5 dB or more. 10/100BASE-X and 1000BASE-TX reach The following table lists maximum transmission distances for 10/100BASE-X and 1000BASETX Ethernet cables.
Auto MDIX Port on A Full-duplex Port on B Full-duplex Remarks Recommendations Both sides require the same mode. Avaya recommends that you use this configuration if you require full-duplex, but the configuration does not support AutoNegotiation. Auto-Negotiation cannot detect the identities of neighbors or shut down misconnected ports. Upper-layer protocols perform these functions.
Hardware fundamentals and guidelines If a 10/100/1000 Mbit/s port that supports CANA is in a MLT group that has 10/100BASETX ports, or any other port type that does not support CANA, then use CANA only if it does not conflict with MLT abilities. 30 Network Design Reference for Avaya VSP 4000 Comments? infodev@avaya.
Chapter 5: Optical routing design The Avaya optical routing system uses coarse wavelength division multiplexing (CWDM) in a grid of eight optical wavelengths. Use the Avaya optical routing system to maximize bandwidth on a single optical fiber. This section provides optical routing system information that you can use to help design your network.
Optical routing design • Optical multiplexer/demultiplexers (OMUX) • Optical shelf to house the multiplexers OADMs drop or add a single wavelength from or to an optical fiber. For the list of supported optical devices on the VSP 4000 platform for the current release, see Supported optical devices on page 24. 32 Network Design Reference for Avaya VSP 4000 Comments? infodev@avaya.
Chapter 6: Platform redundancy This section includes recommendations to provide a fault tolerant platform. Power redundancy The Avaya VSP 4850GTS-PWR+ model supports dual 54V 1000W Power over Ethernet Plus (PoE+) AC power supplies. This model supports two external field replaceable power supplies. You can install a secondary power supply to provide redundancy, load sharing, and add Power over Ethernet Plus (PoE+) power budget on PWR+ models.
Platform redundancy Input/output port redundancy You can protect I/O ports using a link aggregation mechanism. MultiLink Trunking (MLT), which is compatible with 802.3ad static, provides a load sharing and failover mechanism to protect against module, port, fiber, or complete link failures. You can use MLT with Link Access Control Protocol (LACP) disabled or use LACP enabled by itself. Configuration redundancy You can define primary and backup configuration file paths.
Chapter 7: Link redundancy You can build link redundancy into your network to • help eliminate a single point of failure in your network (provide physical and link layer redundancy) • prevent a service interruption caused by a faulty link (provide link layer redundancy) This chapter explains the following design options that you can use to achieve link redundancy (provide alternate data paths) : • physical layer redundancy • Multilink Trunking • 802.
Link redundancy Figure 6: 1000BASE-X RFI End-to-end fault detection and VLACP Because remote fault indication (RFI) terminates at the next Ethernet hop, the device that uses only RFI cannot determine failures on an end-to-end basis over multiple hops. However, you can use Virtual Link Aggregation Control Protocol (VLACP) to provide an endto-end failure detection mechanism. You can configure VLACP on a port and enable it over single links or Multilink trunks (MLT).
Physical layer redundancy You can use VLACP with MLT to enhance its capabilities and provide quick failure detection. With VLACP, the device can detect far-end failures, which permits MLT to failover properly when end-to-end connectivity is not guaranteed for some links in an aggregation group. To minimize network outages, you can also use VLACP to switch traffic around entire network devices before Layer 3 protocols detect a network failure.
Link redundancy Figure 8: Problem description (2 of 2) However, if you use VLACP to detect far-end failures and allow MLT to failover when end-toend connectivity is not guaranteed for links in an aggregation group, then VLACP prevents the failure scenario in the preceding figure. Avaya recommends that you use the following guidelines for VLACP implementation: • Do not use VLACP on configured LACP MLTs because LACP provides the same functionality as VLACP for link failure.
Multilink Trunking in the forwarding state. You can avoid this situation with consistent port level VLACP configuration. • Configure VLACP on an individual port basis. The port can be either an individual port or an MLT member. Each VLACP-enabled port periodically sends VLACP PDUs. This action allows the exchange of VLACP PDUs from an end-to-end perspective. If a particular link does not receive VLACP PDUs, the platform shuts the link down after the expiry timeout occurs (timeout scale x periodic time).
Link redundancy MLT and spanning tree protocols The implementation of 802.1w (Rapid Spanning Tree Protocol—RSTP) and 802.1s (Multiple Spanning Tree Protocol—MSTP), provides a path cost calculation method.
802.3ad-based link aggregation To enable tagging on ports that belong to a LAG, first disable LACP on the port, enable tagging on the port, and then enable LACP. Important: Enabling IS-IS is not supported on LACP based MLT. LACP and spanning tree interaction Only the physical link state or the LACP peer status affects the operation of LACP. After a link goes up and down, the LACP module receives notification. The spanning tree forwarding state does not affect the operation of the LACP module.
Link redundancy 42 Network Design Reference for Avaya VSP 4000 Comments? infodev@avaya.
Chapter 8: Layer 2 loop prevention This section provides information about how to use bandwidth and network resources efficiently, and to prevent Layer 2 data loops. Use the information in this section to use loop prevention mechanisms. Loop prevention and detection In certain network designs, loops can form. For example, loops can form if you have incorrect configuration or cabling. There are two solutions to detect loops: Loop Detect, and Simple Loop Prevention Protocol (SLPP).
Layer 2 loop prevention untagged and tagged IEEE 802.1Q VLAN link configurations. You determine to which VLANs a switch sends SLPP test packets to. All port members of the SLPP-enabled VLAN replicate the packets. Use the information in this section to understand the considerations and recommendations to configure SLPP in your network: • You must enable SLPP packet receive on each port to detect a loop. • SLPP test packets (SLPP-PDU) are forwarded for each VLAN.
Loop prevention and detection Parameter Transmission interval Configuration 500 ms (default) Loop Detect Use the Loop Detect feature at the edge of a network to prevent loops. This feature detects whether the same MAC address appears on different ports. Loop Detect can disable a VLAN or a port. The Loop Detect feature can also disable a group of ports if it detects the same MAC address on two different ports five times in a configurable amount of time.
Layer 2 loop prevention SLPP example scenarios The following examples illustrate some situations where layer 2 loops can occur and how SLPP prevents loops in those cases. Scenario 1: VSP 4000 as an edge router Scenario 1 demonstrates a triangular setup with ERS 8800 switches as IST peers, and VSP 4000 on the edge. From VSP 4000, there are four links that are part of the same MLT, with SLPP enabled on the VSP 4000 ports. Because the MLT ports are misconfigured, loops can occur.
SLPP example scenarios Figure 10: VSP 4000 as an edge router and with an additional link with ERS 8800 The SLPP PDUs generated by VSP 4000 return to the same DUT through the additional link. After the threshold value set on the SLPP enabled ports is reached, the ports go down. Scenario 3: VSP 4000 as a BEB connected to an edge router In scenario 3, VSP 4000 acts as a BEB and is connected to a BayStack device. SLPP is enabled on the UNI ports of the VSP 4000.
Layer 2 loop prevention Figure 11: VSP 4000 as a BEB connected to an edge router In this scenario, either SLPP or RSTP/MSTP can bring the ports down. Scenario 4: Two VSP 4000 switches acting as BEBs In scenario 4, there are two VSP 4000 devices that act as BEBs and are connected to each other through MLT, with two BayStack devices connected to each of the BEBs. The interface that connects the VSP 4000 interfaces is an ISIS interface with STP disabled. SLPP is enabled in the UNI ports of the VSP 4000.
SLPP example scenarios Figure 12: Two VSP 4000 switches acting as BEBs The SLPP PDUs generated by the VSP 4000-1 return to itself through VSP 4000–2, Bay Stack 2, and Bay Stack 1. After reaching the threshold value, the SLPP brings the port down, therefore eliminating the loop.
Layer 2 loop prevention 50 Network Design Reference for Avaya VSP 4000 Comments? infodev@avaya.
Chapter 9: Spanning tree Spanning tree prevents loops in switched networks. Virtual Services Platform 4000 supports Rapid Spanning Tree Protocol (RSTP) and Multiple Spanning Tree Protocol (MSTP). This section describes issues to consider when you configure spanning tree protocols. For more information about spanning tree protocols, see Avaya Virtual Services Platform 4000 Configuration — VLANs and Spanning Tree, NN46251-500.
Spanning tree Figure 13: VLAN isolation MSTP and RSTP considerations The Spanning Tree Protocol (STP) provides loop protection and recovery, but it is slow to respond to a topology change in the network (for example, a dysfunctional link in a network). The RSTP (IEEE 802.1w) and MSTP (IEEE 802.1s) protocols reduce the recovery time after a network failure. RSTP and MSTP also maintain a backward compatibility with IEEE 802.1D. Typically, the recovery time of RSTP and MSTP is less than 1 second.
MSTP and RSTP considerations Use MSTP to configure MSTIs on the same switch. Each MSTI can include one or more VLANs. In MSTP mode you can configure up to 64 instances. Instance 0 or Common and Internal Spanning Tree (CIST) is the default group, which includes default VLAN 1. Instances 1 to 63 are MSTIs. RSTP and MSTP provide a global spanning tree parameter, called version, for backward compatibility with legacy STP.
Spanning tree 54 Network Design Reference for Avaya VSP 4000 Comments? infodev@avaya.
Chapter 10: Layer 3 network design This section describes Layer 3 design considerations that you need to understand to properly design an efficient and robust network. VRF Lite The Virtual Services Platform 4000 supports the Virtual Router Forwarding (VRF) Lite feature, which supports many virtual routers, each with its own routing domain. VRF Lite virtualizes the routing tables to form independent routing domains, which eliminates the need for multiple physical routers.
Layer 3 network design VRF Lite architecture examples VRF Lite enables a router to act as many routers. This provides virtual traffic separation for each user and provides security. For example, you can use VRF Lite to • provide different departments within a company with site-to-site connectivity as well as Internet access • provide centralized and shared access to data centers. The following figure shows how VRF Lite can emulate VPNs.
Virtual Router Redundancy Protocol example, they want to access the Internet, data storage, VoIP-PSTN, or call signaling services. To interconnect VRF instances, you can use an external firewall that supports virtualization, or use inter-VRF forwarding for specific services. Using the inter-VRF solution, you can use routing policies and static routes to inject IP subnets from one VRF instance to another, and filters to restrict access to certain protocols. The following figure shows inter-VRF forwarding.
Layer 3 network design enable BackupMaster on the backup router, the backup router no longer switches traffic to the VRRP Master. Instead the BackupMaster routes all traffic received on the BackupMaster IP interface according to the switch routing table. Figure 17: VRRP with BackupMaster Avaya recommends that you stagger VRRP instances on a network or subnet basis. The following figure shows the VRRP Masters and BackupMasters for two subnets.
Virtual Router Redundancy Protocol configuring the VRRP hold down timer to a minimum of 1.5 times the IGP convergence time is sufficient. For OSPF, Avaya recommends that you use a value of 90 seconds if you use the default OSPF timers. • Implement VRRP BackupMaster for an active-active configuration (BackupMaster works across multiple switches that participate in the same VRRP domain.). • Configure VRRP priority as 200 to configure VRRP Master.
Layer 3 network design Figure 19: VRRP and STG configurations In this figure, configuration A is optimal because VRRP convergence occurs within 2 to 3 seconds. In configuration A, three spanning tree instances exist and VRRP runs on the link between the two routers. Spanning tree instance 2 exists on the link between the two routers, which separates the link between the two routers from the spanning tree instances found on the other devices. All uplinks are active.
Virtual Router Redundancy Protocol Figure 20: ICMP redirect messages If network clients do not recognize ICMP redirect messages, disable ICMP redirect messages on Avaya Virtual Services Platform 4000 to avoid excessive ICMP redirect messages. Avaya recommends the network designs shown in the following figures. Ensure that the routing path to the destination through both routing switches has the same metric to the destination. One hop goes from 30.30.30.0 to 10.10.10.
Layer 3 network design Open Shortest Path First Use OSPF to ensure that the switch can communicate with other OSPF-speaking routers. This section describes some general design considerations and presents a number of design scenarios for OSPF. For more information about OSPF concepts and configuration, see Avaya Virtual Services Platform 4000 Configuration — OSPF and RIP, NN46251-506. OSPF LSA limits To determine OSPF link state advertisement (LSA) limits: 1.
Open Shortest Path First • Minimize the number of OSPF areas for each switch to avoid excessive shortest path calculations. The switch executes the Djikstra algorithm for each area separately. • Ensure that the OSPF dead interval is at least four times the OSPF hello interval • Use MD5 authentication on untrusted OSPF links. • Use stub or NSSA areas as much as possible to reduce CPU overhead.
Layer 3 network design 3. Configure the IP address, subnet mask, and VLAN ID for the port. 4. Disable RIP on the port, if you do not need it. 5. Enable OSPF for the port. After you configure S2, the two switches elect a designated router (DR) and a backup designated router (BDR). They exchange hello packets to synchronize their link state databases (LSDB). The following figure shows a configuration in which OSPF operates on three switches. OSPF performs routing on two subnets in one OSPF area.
Open Shortest Path First The following figure shows an example where OSPF operates on two subnets in two OSPF areas. S2 becomes the ABR for both networks. Figure 24: Example 3: OSPF on two subnets in two areas The routers in scenario 3 use the following configuration: • S1 has an OSPF router ID of 1.1.1.1. The OSPF port uses an IP address of 192.168.10.1, which is in OSPF area 1. • S2 has an OSPF router ID of 1.1.1.2. One port uses an IP address of 192.168.10.2, which is in OSPF area 1.
Layer 3 network design In an environment with a mix of non-Avaya and Avaya switches and routers, you may need to manually modify the OSPF parameter RtrDeadInterval to 40 seconds. Border Gateway Protocol Use the Border Gateway Protocol (BGP) to ensure that the switch can communicate with other BGP-speaking routers on the Internet backbone. BGP is an exterior gateway protocol that exchanges network reachability information with other BGP systems in the same or other autonomous systems (AS).
Border Gateway Protocol • For routers that support both BGP and OSPF, you must configure the OSPF router ID and the BGP identifier to the same IP address. The BGP router ID automatically uses the OSPF router ID. • In configurations where BGP speakers reside on routers that have multiple network connections over multiple IP interfaces (the typical case for IBGP speakers), consider using the address of the circuitless (virtual) IP interface as the local peer address.
Layer 3 network design Figure 25: BGP and Internet peering In cases where the Internet connection is single-homed, to reduce the size of the routing table, Avaya recommends that you advertise Internet routes as the default route to the IGP. The VSP 4000 supports a total of 16000 eBGP routes. The maximum FIB size for IPv4 routes is also 16000. Routing domain interconnection with BGP You can implement BGP so that autonomous routing domains, such as OSPF routing domains, connect.
Border Gateway Protocol Figure 27: BGP and edge aggregation BGP and ISP segmentation You can use the platform as a peering point between different regions or ASs that belong to the same ISP. In such cases, you can define a region as an OSPF area, an AS, or a part of an AS. You can divide the AS into multiple regions that each run different IGPs. Interconnect regions logically by using a full IBGP mesh. Each region then injects its IGP routes into IBGP and also injects a default route inside the region.
Layer 3 network design Figure 28: Multiple regions separated by IBGP In the preceding figure, consider the following • The AS is divided into three regions that each run different and independent IGPs. • Regions logically interconnect by using a full-mesh IBGP, which also provides Internet connectivity. • Internal nonBGP routers in each region default to the BGP border router, which contains all routes.
Border Gateway Protocol Figure 29: Multiple regions separated by EBGP You can obtain AS numbers from the Inter-Network Information Center (NIC) or use private AS numbers. If you use private AS numbers, be sure to design your Internet connectivity carefully. For example, you can introduce a central, well-known AS to provide interconnections between all private ASs and the Internet. Before it propagates the BGP updates, this central AS strips the private AS numbers to prevent them from leaking to providers.
Layer 3 network design IP routed interface scaling Virtual Services Platform 4000 supports up to 256 IP routed interfaces. When you configure a large number of IP routed interfaces, use passive interfaces on most of the configured interfaces. You can make very few interfaces active. 72 Network Design Reference for Avaya VSP 4000 Comments? infodev@avaya.
Chapter 11: SPBM design guidelines Shortest Path Bridging MAC (SPBM) is a next generation virtualization technology that revolutionizes the design, deployment, and operations of enterprise edge campus core networks and data centers. The benefits of the technology are clearly evident in its ability to provide massive scalability while at the same time reducing the complexity of the network.
SPBM design guidelines B-MAC An SPBM backbone includes Backbone Edge Bridges (BEB) and Backbone Core Bridges (BCB). A BEB performs the same functionality as a BCB, but it also terminates one or more Virtual Service Networks (VSNs). A BCB does not terminate any VSNs and is unaware of the VSN traffic it transports. A BCB simply knows how to reach any other BEB in the SPBM backbone.
VLANs without member ports Encapsulating customer MAC addresses in backbone MAC addresses greatly improves network scalability (no end-user C-MAC learning required in the core) and also significantly improves network robustness (loops have no effect on the backbone infrastructure). The following figure shows the components of a basic SPBM architecture. Figure 31: SPBM basic architecture VLANs without member ports The ERS 8800 manages VLANs without member ports differently than the VSP 9000 and VSP 4000.
SPBM design guidelines VSP 9000 and VSP 4000 implementation If a VLAN is attached to an I-SID there must be another instance of that same I-SID in the SPBM network. • If there is another instance of that I-SID, the device designates that VLAN as operationally up regardless of whether it has a member port or not. When the VLAN is operationally up, the IP address of the VLAN will be in the routing table.
Implementation options can participate in the same Layer 2 or Layer 3 VSN. This same simplicity extends to provisioning the services to run above the SPBM backbone: • To create a Layer 2 VSN, associate an I-SID number with an edge VLAN. • To create a Layer 3 VSN, associate an I-SID number with a VRF and configure the desired IS-IS IP route redistribution within the newly created Layer 3 VSN. Note: No service provisioning is needed on the core BCB SPBM switches.
SPBM design guidelines Figure 32: SPBM support for campus and data center architecture Within the SPBM architecture, you can implement multiple options. The following figure shows all the options that SPBM supports. 78 Network Design Reference for Avaya VSP 4000 Comments? infodev@avaya.
Implementation options Figure 33: SPBM implementation options A—IP shortcut IP shortcuts forward standard IP packets over IS-IS. This option enables you to forward IP over the SPBM core, which is a simpler method than traditional IP routing or MPLS. SPBM nodes propagate Layer 3 reachability as leaf information in the IS-IS link state packets (LSP) using Extended IP reachability TLV 135, which contains routing information such as neighbors and locally configured subnets.
SPBM design guidelines In Figure 33: SPBM implementation options on page 79, node VSP-G acts as a BCB for the service, and has no IP configuration. B—Layer 2 VSN A Layer 2 Virtual Services Network (VSN) bridges customer VLANs (C-VLANs) over the SPBM core infrastructure. A Layer 2 VSN associates a C-VLAN with an I-SID, which is then virtualized across the backbone. All VLANs in the network that share the same I-SID can participate in the same VSN.
Implementation options 12 (I-SID 12990012) on the VRF instance configured. Note that for these VSNs, node VSP-G acts as a BEB. E—Layer 3 VSN Layer 3 VSNs are very similar to Layer 2 VSNs. The difference between the two is that Layer 2 VSNs associate I-SIDs with VLANs. Layer 3 VSNs associate I-SIDs with VRFs.
SPBM design guidelines Figure 34: Multi-tenant SPBM metro network To illustrate the versatility and robustness of SPBM even further, the following figure shows a logical view of multiple tenants in a ring topology. In this architecture, each tenant has their own domain where some users have VLAN requirements and are using Layer 2 VSNs and others have VRF requirements and are using Layer 3 VSNs. In all three domains, they can share data center resources across the SPBM network.
Reference architectures Figure 35: SPBM ring topology with shared data centers Reference architectures SPBM has a straightforward architecture that simply forwards encapsulated C-MACs across the backbone. Because the B-MAC header stays the same across the network, there is no need to swap a label or do a route lookup at each node. This architecture allows the frame to follow the most efficient forwarding path from end to end.
SPBM design guidelines Figure 36: SPBM basic architecture Provisioning an SPBM core is as simple as enabling SPBM and IS-IS globally on all the nodes and on the core facing links. To migrate an existing edge configuration into an SPBM network is just as simple. The boundary between the MAC-in-MAC SPBM domain and the 802.1Q domain is handled by the BEBs. At the BEBs, VLANs or VRFs are mapped into I-SIDs based on the local service provisioning.
Reference architectures Figure 37: Access to the SPBM Core For Layer 2 virtualized bridging (Layer 2 VSN), identify all the VLANs that you want to migrate into SPBM and assign them to an I-SID on the BEB. For Layer 3 virtualized routing (Layer 3 VSN), map IPv4-enabled VLANs to VRFs, create an IP VPN instance on the VRF, assign an I-SID to the VRF, and then configure the desired IP redistribution of IP routes into IS-IS. All BEBs that have the same I-SID configured can participate in the same VSN.
SPBM design guidelines • IPv4 multicast routed traffic on the Global Router (IP shortcuts with IP multicast over SPBM) • IPv4 multicast routed traffic using a VRF (Layer 3 VSN with IP multicast over SPBM) Campus architecture For migration purposes, you can add SPBM to an existing network that has SMLT configured. In fact, if there are other protocols already running in the network such as Open Shortest Path First (OSPF), you can leave them in place too.
Reference architectures SID instance and then associated with either a VLAN in an Layer 2 VSN or terminated into a VRF in an Layer 3 VSN. You can also terminate the C-VLAN into the default router, which uses IP shortcuts to IP route over the SPBM core. In an SPBM network design, the only nodes where it makes sense to have an SMLT cluster configuration is on the BEB nodes where VSN services terminate.
SPBM design guidelines Figure 39: IP shortcut scenario to move traffic between data centers The following figure uses Layer 3 VSNs to route VRFs between the edge distribution and the core. The VRFs are attached to I-SIDs and use Layer 3 virtualization. 88 Network Design Reference for Avaya VSP 4000 Comments? infodev@avaya.
Reference architectures Figure 40: VRF scenario to move traffic between data centers Multicast architecture Networks today either have inefficient bridged IP multicast networks (IGMP) or IP multicast networks that require multiple protocols that are complex to configure and operate.
SPBM design guidelines 1. Layer 2 Virtual Services Network with IGMP support on the access networks for optimized forwarding of IP multicast traffic in a bridged network (L2 VSN with multicast) 2. IP multicast routing support for Global Routing Table using SPB in the core (IP Shortcuts with multicast) 3.
Reference architectures Figure 41: IP multicast over SPBM streams The following list describes how multicast senders and receivers connect to the SPBM cloud using BEBs in the preceding diagram: 1. The sender sends multicast traffic with group IP address 233.252.0.1. 2. After the BEB receives the IP multicast stream from the sender, the BEB allocates data I-SID 16000001 for the S,G multicast stream.
SPBM design guidelines Large data center architecture SPBM supports data centers with IP shortcuts, Layer 2 VSNs, or Layer 3 VSNs. If you use vMotion, you must use Layer 2 between data centers (Layer 2 VSN). With Layer 2 VSNs, you can add IP addresses to the VLAN on both data centers and run Virtual Router Redundancy Protocol (VRRP) between them to allow the ESX server to route to the rest of the network. The following figure shows an SPBM topology of a large data center.
Reference architectures Figure 43: Traditional routing before moving VMs A VM is a virtual server. When you move a VM, the virtual server is moved as is. This action means that the IP addresses of that server remain the same after the server is moved from one data center to the other. This in turn dictates that the same IP subnet (and hence VLAN) exist in both data centers. In the following figure, the VM moved from the data center on the left to the data center on the right.
SPBM design guidelines Figure 44: Traditional routing after moving VMs Optimized data center routing of VMs: Two features make a data center optimized: • VLAN routers in the Layer 2 domain (green icons) • VRRP BackupMaster The VLAN routers use lookup tables to determine the best path to route incoming traffic (red dots) to the destination VM. VRRP BackupMaster solves the problem of traffic congestion on the IST. Because there can be only one VRRP Master, all other interfaces are in backup mode.
Reference architectures Figure 45: Optimized routing before moving VMs In the traditional data center, chaos resulted after many VMs were moved. In an optimized data center as shown in the following figure, the incoming traffic enters the Layer 2 domain where an edge switch uses Inter-VSN routing to attach an I-SID to a VLAN. The I-SID bridges traffic directly to the destination.
SPBM design guidelines Figure 46: Optimized routing after moving VMs Solution-specific reference architectures The following sections describe solution-specific reference architectures, like for example for Video Surveillance or Data Center implementation, using the VSP 4000. Multi tenant — fabric connect This fabric connect based solution leverages the fabric capabilities of the VSP platforms; a VSP 7000 core and a VSP 4000 edge.
Solution-specific reference architectures Figure 47: Small core — Multi-tenant The following list outlines the benefits of the fabric connect based solution: • end-point provisioning • fast failover • simple to configure • L2 and L3 virtualized Hosted data center management solution — ETREE In some hosted data center solutions, the hosting center operating company takes responsibility for managing customer servers.
SPBM design guidelines Figure 48: Data center hosting private VLAN The following list outlines the benefits of the hosted data center management solution: • Easy end-point provisioning • optimal resiliency • secure tenant separation Video surveillance — bridged In a video surveillance solution, optimal traffic forwarding is a key requirement to ensure proper operation of the camera and recorder solutions. However, signaling is also important to ensure quick channel switching.
Solution-specific reference architectures Figure 49: Deployment scenario — Bridged video surveillance and IP camera deployment for transportation, airports, and government The following list outlines the benefits of the bridged video surveillance solution: • Easy end-point provisioning • sub second resiliency and mc forwarding • secure tenant separation • quick camera switching Video surveillance — routed In a video surveillance solution, optimal traffic forwarding is a key requirement to ensure proper o
SPBM design guidelines Figure 50: Deployment scenario — Routed video surveillance and IP camera deployment for transportation, airports, and government The following list outlines the benefits of the routed video surveillance solution: • Easy end-point provisioning • optimal resiliency and mc forwarding • secure tenant separation • rapid channel/camera switching Metro-Ethernet Provider solution VSP 9000, ERS 8000, VSP 7000 and VSP 4000 provide an end-to-end Metro-Ethernet Provider solution.
Best practices Figure 51: Metro ring access solution The following list outlines the benefits of the Metro-Ethernet Provider solution: • Easy end-point provisioning • optimal resiliency • secure tenant separation Best practices This section provides best practices to configure an SPBM network. IS-IS The following list identifies best practices for IS-IS: • Avaya recommends that you change the IS-IS system ID from the default B-MAC value to a recognizable address to easily identify a switch.
SPBM design guidelines - If you do manually change the system ID, take the necessary steps to ensure no duplication exists in the network. • Create two B-VLANs to allow load distribution over both B-VLANs. This configuration is required if you use SMLT. Even if you do not use SMLT in the network, this is still good practice as adding a second B-VLAN to an existing configuration allows SPBM to load balance traffic across two equal cost multipaths if the physical topology grants it.
SPBM restrictions and limitations Important: You must configure the MIP at the same level as the Maintenance Association Endpoints (MEP) on all switches in the SPBM network. Example of a configuration using best practices spbm-id : 1 BVID #1 & BVID #2 : 4040, 4041 (ignore warning message when configuring) nick-name : b:b0: MEP-id : md.ma.
SPBM design guidelines customer networks, if you use STG 63 or MSTI 62 in the configuration, you must delete STG 63 or MSTI 62 before you can configure SPBM. • You must configure SPBM B-VLANs on all devices in the same MSTP region. MSTP requires this configuration to generate the correct digest. SPBM IS-IS The following list identifies restrictions and limitations associated with SPBM IS-IS: • The current release does not support IP over IS-IS as defined by RFC 1195.
IP multicast over SPBM restrictions IP multicast over SPBM restrictions Review the following restrictions for the IP multicast over SPBM feature. IGMP The BEB must be the only IGMP querier in the network. If the BEB receives an IGMP query from any other device, it causes unpredictable behavior, including traffic loss. SPBM supports IGMP Snooping on a C-VLAN, but it does not support PIM on a C-VLAN. If you enable IGMP Snooping on a C-VLAN, then its operating mode is Layer 2 VSN with IP multicast over SPBM.
SPBM design guidelines 106 Network Design Reference for Avaya VSP 4000 Comments? infodev@avaya.
Chapter 12: IP multicast network design Use multicast routing protocols to efficiently distribute a single data source among multiple users in the network. This section provides information about how to design networks that support IP multicast routing. For more information about multicast routing, see Avaya Virtual Services Platform 4000 Configuration — IP Multicast Routing Protocols, NN46251-504. For design guidelines on IP Multicast over SPBM, see SPBM design guidelines on page 73.
IP multicast network design Multicast flow distribution over MLT MultiLink Trunking (MLT) distributes multicast streams over a multilink trunk based on the source MAC address and the destination MAC address. As a result, the load is distributed on different ports of the MLT more evenly. This functionality is enabled by default on the VSP 4000 and cannot be manually configured. Multicast scalability design rules The following section lists the design rules to increase multicast route scaling.
IP multicast address range restrictions S2 is on a different VLAN than VLAN 3, traffic takes a single path to switch S1 where the receivers are located. Figure 52: IP multicast sources and receivers on interconnected VLANs 6. Avaya recommends the use of Static group-range-to-RP mappings in an SMLT topology as opposed to RP set learning via the Bootstrap Router (BSR) mechanism.
IP multicast network design subnets does not exist for multicast group addresses. Consequently, the usual unicast conventions—where you reserve the all 0s subnets, all 1s subnets, all 0s host addresses, and all 1s host addresses—do not apply. Internet Assigned Numbers Authority (IANA) reserves addresses from 224.0.0.0 through 224.0.0.255 for link-local network applications. Multicast-capable routers do not forward packets with an address in this range. For example, Open Shortest Path First (OSPF) uses 224.
Multicast MAC address mapping considerations 225.129.1.1, 239.1.1.1, 239.129.1.1 map to the same 01:00:5E:01:01:01 multicast MAC address. Figure 53: Multicast IP address to MAC address mapping Most Ethernet switches handle Ethernet multicast by mapping a multicast MAC address to multiple switch ports in the MAC address table. Therefore, when you design the group addresses for multicast applications, take care to efficiently distribute streams only to hosts that are receivers.
IP multicast network design 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.
IGMP Layer 2 Querier Note: If you enable the explicit host tracking option on an IGMPv3 interface, you cannot downgrade to IGMPv1 or IGMPv2. You must disable explicit host tracking to downgrade the IGMP version. IGMP Layer 2 Querier In a multicast network, if you only need to use Layer 2 switching for the multicast traffic, you do not need multicast routing. However, you must have an IGMP querier on the network for multicast traffic to flow from sources to receivers.
IP multicast network design Multicast MAC filtering Certain network applications, such as the Microsoft Network Load Balancing solution, require multiple hosts to share a multicast MAC address. Instead of flooding all ports in the VLAN with this multicast traffic, you can use Multicast MAC filtering to forward traffic to a configured subset of the ports in the VLAN. This multicast MAC address is not an IP multicast MAC address. At a minimum, map the multicast MAC address to a set of ports within the VLAN.
Multicast for multimedia Multicast access policies can apply to a routed PIM interface if Internet Group Management Protocol (IGMP) reports the reception of multicast traffic. The following rules and limitations apply to IGMP access policy parameters when you use them with IGMP instead of PIM: • The static member parameter applies to IGMP snooping and PIM on both interconnected links and edge ports.
IP multicast network design Multiple user mode allows several users on the same port or VLAN. If one user leaves the group and other receivers exist for the same stream, the stream continues. The switch tracks the number of receivers that join a given group. For multiple user mode to operate properly, do not suppress reports. This ensures that the switch properly tracks the correct number of receivers on an interface.
Multicast for multimedia value of two, translate to leave latencies of six tenths of a second and two seconds, respectively. When you choose an LMQI, consider all of these factors to determine the best configuration for the given application and network. Test that value to ensure that it provides the best performance.
IP multicast network design 118 Network Design Reference for Avaya VSP 4000 Comments? infodev@avaya.
Chapter 13: System and network stability and security Use the information in this section to design and implement a secure network. You must provide security mechanisms to prevent your network from attack. If links become congested due to attacks, you can immediately halt end-user services. During the design phase, study availability issues for each layer. To provide additional network security, you can use the Avaya VSP 9000 or your own high-performance stateful firewalls.
System and network stability and security queues to guarantee proper handling of control packets regardless of the switch load. In turn, this guarantees the stability of the network. Prioritization also guarantees that applications that use many broadcasts are handled with lower priority. You cannot view, configure, or modify control traffic queues.
Damage prevention For more information, see Avaya Virtual Services Platform 4000 Security, NN46251-601. 4. Prevent unknown devices from influencing the spanning tree topology. Packet spoofing You can stop spoofed IP packets by configuring the switch to only forward IP packets that contain the correct source IP address of your network. By denying all invalid source IP addresses, you minimize the chance that your network is the source of a spoofed DoS attack.
System and network stability and security You can also enable the spoof-detect feature on a port. For more information about the spoof-detect feature, see Avaya Virtual Services Platform 4000 Configuration — VLANs and Spanning Tree, NN46251-500. High Secure mode To ensure that Virtual Services Platform 4000 does not route packets with an illegal source address of 255.255.255.255 (RFC1812 Section 4.2.2.11 and RFC971 Section 3.2), you can enable High Secure mode. By default, this feature is disabled.
Data plane security Id: Name: PolicyEnable: Mode: Service: Precedence: NetAddrType: NetAddr: NetMask: TrustedHostAddr: TrustedHostUserName: AccessLevel: AccessStrict: Usage: 1 default false allow ftp|http|telnet|ssh 128 any N/A N/A N/A none readOnly false 0 If you disable access-strict (false), the policy looks at the value for accesslevel, and then the system applies the policy to anyone with equivalent rights or higher.
System and network stability and security Routing protocol security You can protect OSPF and BGP updates with a Message Digest 5 (MD5) key on each interface. At most, you can configure two MD5 keys for each interface. You can also use multiple MD5 key configurations for MD5 transitions without bringing down an interface. For more information, see Avaya Virtual Services Platform 4000 Configuration — OSPF and RIP, NN46251-506 and Avaya Virtual Services Platform 4000 Configuration — BGP Services, NN46251-507.
Control plane security Figure 54: Access levels Avaya recommends that you use access policies for in-band management to secure access to the switch. By default, all services are denied. You must enable the default policy or enable a custom policy to provide access. A lower precedence takes higher priority if you use multiple policies. Preference 120 has priority over preference 128. RADIUS authentication You can enforce access control by using RADIUS.
System and network stability and security Figure 55: 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 the shared secret matches what is defined in the RADIUS server. • Provide the attribute value. • Provide the use by value.
Control plane security SSH determines identities. During the logon process, the SSH client asks for digital proof of the identity of the user. • Encryption SSH uses encryption algorithms to scramble data. This data is rendered unintelligible except to the intended receiver. • Integrity SSH guarantees that data is transmitted from the sender to the receiver without alteration. If a third party captures and modifies the traffic, SSH detects this alteration.
System and network stability and security Figure 56: Firewall load balancing configuration Use this configuration to redirect incoming and outgoing traffic to a group of firewalls and to automatically load balance across multiple firewalls.
Chapter 14: QoS design guidelines This section provides design guidelines to provide Quality of Service (QoS) to user traffic on the network. For more information about fundamental QoS mechanisms, and how to configure QoS, see Avaya Virtual Services Platform 4000 Configuration — QoS and IP Filtering, NN46251-502. QoS mechanisms Virtual Services Platform 4000 has a solid, well-defined architecture to handle QoS in an efficient and effective manner.
QoS design guidelines Traffic category Application example ASC Real-Time, Delay Intolerant IP telephony; interhuman communication Real-Time, Delay Tolerant Video conferencing; interhuman Platinum communication.
QoS mechanisms Figure 57: Filter decision-making process Configure filters through the use of Access Control Lists (ACL) and Access Control Entries (ACE), which are implemented in hardware. An ACL can include both security and QoS type ACEs. The platform supports 2048 ACLs and 1000 ACEs for each ACL to a maximum of 16 000 ACEs for each plaform. The following steps summarize the filter configuration process: 1. Determine your desired match fields. 2. Create an ACL. 3. Create an ACE within the ACL. 4.
QoS design guidelines VSP 4000 supports two-rate, three-color marking for policers as described in RFC 2698. Policers mark packets as Green, Yellow, or Red. Red packets are dropped automatically. Out of profile packets cannot be re-marked to a lower QoS level. The system can perform rate metering only on a Layer 3 basis. Traffic shapers buffer and delay violating traffic. These operations occur at the egress level. Virtual Services Platform 4000 supports traffic shaping at the port level.
QoS interface considerations Enable DiffServ Access DiffServ 802.1p Override Routed Packet Tagged Ingress Packet Internal QoS Derived From Egress Packet DSCP Derived from Egress Packet 802.1p Derived from 1 0, L3T=1 0, L2T=1 0 1 .1p Stays untouched iQoS 1 0, L3T=1 0, L2T=1 X 0 DCSP Stays untouched iQoS 1 1, L3T=0 0, L2T=1 X 1 .1p iQoS iQoS 1 1, L3T=0 0, L2T=1 X 0 Port QoS iQoS iQoS 0 X, L3T=0 0, L2T=1 X 1 .
QoS design guidelines Network congestion and QoS design When you provide QoS in a network, one of the major elements you must consider is congestion, and the traffic management behavior during congestion. Congestion in a network is caused by many different conditions and events, including node failures, link outages, broadcast storms, and user traffic bursts. At a high level, three main types or stages of congestion exist: 1. no congestion 2. bursty congestion 3.
QoS examples and recommendations Bridged traffic If you bridge traffic over the core network, you keep customer VLANs separate (similar to a Virtual Private Network). Normally, a service provider implements VLAN bridging (Layer 2) and no routing. In this case, the 802.1p-bit marking determines the QoS level assigned to each packet. If DiffServ is active on core ports, the level of service received is based on the highest of the DiffServ or 802.1p settings.
QoS design guidelines actions performed on three different traffic flows (VoIP, video conference, and e-mail) over an RPR core network. Figure 59: RPR QoS internetworking Routed traffic If you route traffic over the core network, VLANs are not kept separate. If you configure the port to core, you assume that, for all incoming traffic, the QoS configuration is properly marked. All core switch ports simply read and forward packets. The switch does not re-mark or classify the packets.
QoS examples and recommendations Figure 60: Trusted routed traffic For routed, untrusted traffic, in an access node, packets that enter through a tagged or untagged access port exit through a tagged or untagged core port.
QoS design guidelines 138 Network Design Reference for Avaya VSP 4000 Comments? infodev@avaya.
Chapter 15: Layer 1, 2, and 3 design examples This section provides examples to help design your network. Layer 1 examples deal with the physical network layouts. Layer 2 examples map Virtual Local Area Networks (VLAN) on top of the physical layouts. Layer 3 examples show the routing instances that Avaya recommends to optimize IP for network redundancy. Layer 1 example This section describes a Layer 1 network design example that focuses primarily on the physical network layout.
Layer 1, 2, and 3 design examples Layer 2 example This section describes a Layer 2 network design example that maps VLANs over the physical network layout. Layer 2: Design example The following example shows a redundant device network that uses one VLAN for all switches. To support multiple VLANs, you need 802.1Q tagging on the links with trunks. Figure 62: Layer 2 design example 140 Network Design Reference for Avaya VSP 4000 Comments? infodev@avaya.
Layer 3 example Layer 3 example This section describes a Layer 3 network design example that shows the routing instances that Avaya recommends you use to optimize IP for network redundancy. Layer 3: Design example Figure 63: Layer 3 design example on page 141 uses redundant links.
Layer 1, 2, and 3 design examples 142 Network Design Reference for Avaya VSP 4000 Comments? infodev@avaya.
Chapter 16: Software scaling capabilities This section lists software scaling capabilities of Avaya Virtual Services Platform 4000.
Software scaling capabilities Maximum number supported OSPF VRF support 24 e-BGP peers 12 e-BGP routes 16,000 Address Resolution Protocol (ARP) for each port, VRF, or VLAN (IPv4) 6,000 entries total Circuitless IP interfaces 64 Maximum B-MACs 1000 ECMP routes 1000 ECMP groups 512 groups with a maximum of 4 ECMP paths per group Note: The maximum number of ECMP routes per VSP 4000 system is 1000.
Maximum number supported VRRP interfaces (IPv4) 64 VRRP interfaces fast timers (200 ms) 24 Diagnostics Mirrored ports 49 Remote Mirroring Termination (RMT) ports 4 Filters and QoS Port shapers (IPv4) 50 ACEs per ACL (a combination of Security and QoS 1,000 ACEs) Unique redirect next hop values for ACE Actions (IPv4) Ingress: 1,536, Egress: 256 SPBM C-VLANs per VSP 4000 node 1000 Maximum number of nodes per region 1000 MAC entries 16,000 (combination of ARP entries and Layer 2 MACs) Backbon
Software scaling capabilities Maximum number supported Maximum number of IP interfaces with Multicast enabled 256 Number of remote senders that can be received on 3500 each VSP 4000 node, for the Universal Plug and Play Group (239.255.255.250) Maximum unique multicast streams sourced per VSP 4000 node 1000 T-UNI T-UNI ISIDs per VSP 4000 node 48 Maximum MAC limit on a T-Uni I-SID 32,000 Note: This is also the device limit. 146 Network Design Reference for Avaya VSP 4000 Comments? infodev@avaya.
Chapter 17: Supported standards, RFCs, and MIBs This chapter details the standards, request for comments (RFC), and Management Information Bases (MIB) that Avaya Virtual Services Platform 4000 supports. Supported IEEE standards The following table details the IEEE standards that Avaya Virtual Services Platform 4000 supports. Table 16: Supported IEEE standards IEEE standard Description 802.1aq Shortest Path Bridging (SPB) 802.1D MAC bridges (Spanning Tree) 802.
Supported standards, RFCs, and MIBs IEEE standard Description 802.3i 10BaseT 802.3u 100BaseT 802.3x flow control 802.3z Gigabit Ethernet Supported RFCs The following table and sections list the RFCs that Avaya Virtual Services Platform 4000 supports.
Quality of service Request for comment Description RFC1340 Assigned Numbers RFC1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy RFC1541 Dynamic Host Configuration Protocol1 RFC1542 Clarifications and Extensions for the Bootstrap Protocol RFC1591 DNS Client RFC1812 Router requirements RFC1866 HyperText Markup Language version 2 (HTMLv2) protocol RFC2068 Hypertext Transfer Protocol RFC2131 Dynamic Host Control Protocol (DHCP) RFC2138 RADIUS Authe
Supported standards, RFCs, and MIBs Request for comment RFC2598 Description An Expedited Forwarding PHB Network management Table 19: Supported request for comments Request for comment 150 Description RFC1155 SMI RFC1157 SNMP RFC1215 Convention for defining traps for use with the SNMP RFC1271 Remote Network Monitoring Management Information Base RFC1305 Network Time Protocol v3 Specification, Implementation and Analysis3 RFC1350 The TFTP Protocol (Revision 2) RFC1354 IP Forwarding Table MI
MIBs Request for comment Description RFC2574 User-based Security Model (USM) for v3 of the Simple Network Management Protocol (SNMPv3) RFC2575 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) RFC2576 Coexistence between v1, v2, & v3 of the Internet standard Network Management Framework RFC2819 Remote Network Monitoring Management Information Base MIBs Table 20: Supported request for comments Request for comment Description RFC1156 MIB for network managem
Supported standards, RFCs, and MIBs Request for comment Description RFC2578 Structure of Management Information v2 (SMIv2) RFC2674 Bridges with Traffic MIB RFC2787 Definitions of Managed Objects for the Virtual Router Redundancy Protocol RFC2863 Interface Group MIB RFC2925 Remote Ping, Traceroute & Lookup Operations MIB RFC3416 v2 of the Protocol Operations for the Simple Network Management Protocol (SNMP) RFC4022 Management Information Base for the Transmission Control Protocol (TCP) RFC41
Standard MIBs Standard MIB name Institute of Electrical and Electronics Engineers/ Request for Comments (IEEE/RFC) File name STDMIB6—Simple Network Management Protocol (SNMP) RFC1157 rfc1157.mib STDMIB7—MIB for network management of Transfer Control Protocol/Internet Protocol (TCP/IP) based Internet MIB2 RFC1213 rfc1213.mib STDMIB8—A convention for RFC1215 defining traps for use with SNMP rfc1215.mib STDMIB10—Definitions of RFC1493 Managed Objects for Bridges rfc1493.
Supported standards, RFCs, and MIBs Standard MIB name 154 Institute of Electrical and Electronics Engineers/ Request for Comments (IEEE/RFC) File name STDMIB26e—View-based Access Control Model (VACM) for the SNMP RFC2575 rfc2575.mib STDMIB26f —Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework RFC2576 rfc2576.mib STDMIB29—Definitions of Managed Objects for the Virtual Router Redundancy Protocol RFC2787 rfc2787.
Proprietary MIBs Standard MIB name Institute of Electrical and Electronics Engineers/ Request for Comments (IEEE/RFC) File name STDMIB43—Management RFC4113 Information Base for the User Datagram Protocol (UDP) rfc4113.mib STDMIB44—Entity MIB RFC4133 rfc4133.mib STDMIB45 – Definitions of Managed Power Over Ethernet RFC3621 rfc3621.mib Proprietary MIBs The following table details the proprietary MIBs that Avaya Virtual Services Platform 4000 supports.
Supported standards, RFCs, and MIBs 156 Network Design Reference for Avaya VSP 4000 Comments? infodev@avaya.
Glossary Backbone Core Bridge (BCB) Backbone Core Bridges (BCBs) form the core of the SPBM network. The BCBs are SPBM nodes that do not terminate the VSN services. BCBs forward encapsulated traffic based on the Backbone MAC Destination Address (BMAC-DA). A BCB is unaware of the VSN traffic it transports. A BCB simply knows how to reach any other Backbone Edge Bridges (BEBs) in the SPBM backbone.
Customer MAC (C-MAC) multiplexing (CWDM) Customer MAC (CMAC) For customer MAC (C-MAC) addresses, which is customer traffic, to forward across the service provider back, SPBM uses IEEE 802.1ah Provider Backbone Bridging MAC-in-MAC encapsulation. The system encapsulates C-MAC addresses within a backbone MAC (B-MAC) address pair made up of a BMAC destination address (BMAC-DA) and a BMAC source address (BMAC-SA).
Link Aggregation Control Protocol Data Units (LACPDU) last member query interval (LMQI) The time between when the last IGMP member leaves the group and the stream stops. latency The time between when a node sends a message and receipt of the message by another node; also referred to as propagation delay. Layer 1 Layer 1 is the Physical Layer of the Open System Interconnection (OSI) model.
link aggregation group (LAG) Data Units (LACPDU) link aggregation group (LAG) A group that increases the link speed beyond the limits of one single cable or port, and increases the redundancy for higher availability. load balancing The practice of splitting communication into two (or more) routes or servers. MAC-in-MAC encapsulation MAC-in-MAC encapsulation defines a BMAC-DA and BMAC-SA to identify the backbone source and destination addresses.
Secure Shell (SSH) Protocol Data Units (PDUs) A unit of data that is specified in a protocol of a specific layer and that consists of protocol-control information of the specific layer and possibly user data of that layer. Provider Backbone Bridge (PBB) To forward customer traffic across the service provider backbone, SPBM uses IEEE 802.1ah Provider Backbone Bridging (PBB) MAC-in-MAC encapsulation, which hides the customer MAC (C-MAC) addresses in a backbone MAC (B-MAC) address pair.
Secure Sockets Layer (SSL) Secure Sockets Layer (SSL) An Internet security encryption and authentication protocol for secure point-to-point connections over the Internet and intranets, especially between clients and servers. Service Instance Identifier (I-SID) The SPBM B-MAC header includes a Service Instance Identifier (I-SID) with a length of 24 bits. SPBM uses this I-SID to identify and transmit any virtualized traffic in an encapsulated SPBM frame.
User Datagram Protocol (UDP) diameter. These fibers have a potential bandwidth of 50 to 100 GHz per kilometer. small form factor pluggable (SFP) A hot-swappable input and output enhancement component used with Avaya products to allow gigabit Ethernet ports to link with other gigabit Ethernet ports over various media types. small form factor pluggable plus (SFP+) SFP+ transceivers are similar to SFPs in physical appearance but SFP + transceivers provide Ethernet at 10 gigabit per second (Gb/s).
view-based access control model (VACM) view-based access control model (VACM) Provides context, group access, and group security levels based on a predefined subset of management information base (MIB) objects. Virtual Link Aggregation Control Protocol (VLACP) Virtual Link Aggregation Control Protocol (VLACP) is a Layer 2 handshaking protocol that can detect end-to-end failure between two physical Ethernet interfaces.
