Overview
Logical group objects
Logical group objects are children of the device object. They appear below the device object in the navigation tree. The following logical group objects are created automatically in the navigation tree after the device is discovered.
Properties forms for logical group objects are accessed using the NFM-P navigation tree.
This chapter contains the procedures to configure logical group objects using the navigation tree. See Chapter 3, NFM-P navigation tree for more information about using the navigation tree.
Working with CCAG objects
CCAGs are navigation tree objects located below device icons. CCAGs are configured manually using the CCAG object navigation tree menu and subsequent forms. For proper CCAG configuration, a VSM-CCA card must be present in the NE. In the navigation tree, a VSM-CCA card can be opened to show its ports. The ports are indicated by VSM Port x/y/z, which shows port type and the ID of the port.
You must configure the following in the CCAG configuration forms:
-
General properties such as CCAG ID, Description, CCA Rate Enabled, CCA Rate, Access Adapt QoS, and Administrative State
-
CCAG MDA Members which are compatible ports that can belong to a CCAG.
When you create a CCAG, the NFM-P creates virtual paths to be used as interconnections to bind services together. Two unidirectional paths are created: Alpha and Beta. For each path, three virtual ports are created: one for SAP-SAP connections, one for SAP-NET connections, and one for NET-SAP connections. The last two virtual ports are used to bind a service and a network interface together.
A maximum of eight cards can be added to a CCAG, with a maximum of eight CCAGs per NE.
Working with ISA-AA groups
ISA-AA groups provide AA load balancing, scaling, and redundancy on NEs that contain multiple ISA-AA MDAs or ESA VMs. ISA-AA MDAs and ESA VMs cannot be members of the same ISA-AA group.
ISA-AA redundancy protects against card failure and minimizes service disruption during maintenance or protocol signature upgrades.
The NFM-P supports AA group configuration on the 7450 ESS and 7750 SR. An NE can have up to seven ISA-AA groups.
Note: A single-slot chassis does not support AA configuration.
ISA-AA group configuration requires the following:
You can use multiple ISA-AA groups to scale the application of AA policies, and can divide an AA group into partitions that are customized for specific VPN services. Each partition has an AA policy, and supports the configuration of custom protocols, applications, and application groups. Within a partition, you can use application service options, or ASOs, to create multiple application QoS policies (AQPs). AA partitions support statistics collection and data reporting functions.
Note: When you create an ISA-AA group or partition, a default AA policy is automatically created for the group or partition. When you delete a group or partition, the default policy is also deleted.
See Chapter 87, Application assurance for more information about AA groups, partitions, and policies. See To configure an ISA-AA group and ISA-AA partitions for information about creating ISA-AA groups and partitions. See To configure an AA subscriber policy override on an ISA-AA group or partition and To configure Cflowd collectors on an ISA-AA group or partition for information about configuring additional ISA-AA group and partition functions.
Working with ISA-Tunnel groups
ISA-tunnel groups provide redundancy for IPsec tunneling and encryption functions when multiple ISA-IPSEC MDAs or ESA VMs are installed on an NE. ISA-IPSEC redundancy protects against card failure and minimizes service interruption during maintenance or protocol signature upgrades. You can configure up to 16 ISA-Tunnel groups on one NE.
An ISA-tunnel group can operate in one of the following modes:
The primary/backup configuration provides fault tolerance in the event of an MDA failure. An ISA-tunnel group in a primary/backup configuration can contain a maximum of two MDAs.
ISA-IPSEC MDAs and ESA VMs cannot be members of the same ISA-Tunnel group.
Using multiple active members provides load balancing in addition to fault tolerance. This mode of operation is supported on a 7750 SR in chassis mode D or higher, and on a 7450 ESS in mixed mode. You can include up to 16 members in an ISA-tunnel group when the use of multiple active members is enabled.
You can configure an ISA-tunnel group on a 7750 SR or 7450 ESS in mixed mode to act only as an IKEv2 responder during a MC IPsec switchover. This is the automatic behavior for dynamic tunnels, but not for static tunnels. See Chapter 34, IPsec for more information about MC IPsec.
Working with ISA-LNS groups
The NFM-P supports the creation and configuration of ISA-LNS groups. ISA-LNS groups provide LNS PPP session termination on 7750 SR NEs. You can assign an ISA-LNS group to a tunnel group profile or a tunnel profile. When an operational L2TP tunnel is established, peers that are associated with the ISA-LNS group are automatically created. Session traffic is automatically balanced across the available active ISA broadband application MDAs in the group. You can add ISA broadband application MDAs to an ISA-LNS group, and up to four ISA-LNS groups on each NE. See To configure an ISA-LNS group for information about how to create and configure an ISA-LNS group.
You must configure the following on the ISA-LNS groups configuration form:
Note: You can configure an ISA broadband application MDA only on an IOM3-XP module in a 7750 SR -7 or 7750 SR-12, Release 20.10 and earlier.
Working with ISA-NAT groups
An ISA-NAT group provides a redundant NAT function for routing instances using ISA Broadband Applications MDAs or ESA VMs. See Chapter 30, NAT for information about ISA-NAT group configuration.
Working with ISA-Video groups
ISA-Video groups are created to provide packet buffering and packet processing in support of the IPTV video features.
When configured in the router, video ISAs are logically grouped into video groups. An ISA-Video group allows more than one video ISA to be treated as a single logical entity for a specific application, where the system performs a load-balancing function when it assigns tasks to a member of the group.
ISA-Video groups provide a redundancy mechanism to guard against hardware failure within a group. ISA-Video groups pool the processing capacity of all the group members and increase the application throughput because of the increased packet processing capability of the group.
You must configure the following on the ISA-Video groups configuration form:
An ISA-Video group supports ISA or ESA-VM video group members, and not a mix of group members under the same ISA-Video group.
You can add up to four MDAs to an ISA-Video group, and up to four ISA-Video groups on each NE. All members of an ISA-Video group are primary members.
Working with WLAN GW groups
A WLAN GW group is used to represent multiple hardware adapters as a single entity, allowing for warm redundancy between multiple WLAN GW MDAs or ESAs. Only one WLAN GW group can be created per NE. This group can be numbered 1 to 4, but this number must be exclusive and cannot be in use by an ISA-NAT group.
The IOM is the child of the WLAN GW group. The required IOMs should be added before the WLAN GW group is turned administratively up.
WLAN GW members are created automatically by the NE when the WLAN GW group is administratively up, and deleted automatically when the administrative state is down. The number of members is equal to the active IOM limit.
You can globally list WLAN GW groups from the Manage→ ISA Functions→ ISA-WLAN main menu, or from from Manage→ Equipment→Equipment→ISA-WLAN GW Group (WLAN Gateway).
WLAN GW tunnels
WLAN GW tunnels are created dynamically by the NE when the first UE attempts to connect. The tunnel is used to backhaul traffic from the access point or residential gateway to the WLAN GW. The NE creates tunnels on a per-access point or per-residential gateway basis. WLAN GW tunnels terminate on the WLAN-GW MDA or ESA.
WLAN GW tunnels are viewable on the configuration form for base routing instances, VPRN routing instances, group interfaces, and WLAN GW groups. The WLAN GW tunnels tab lists the WLAN GW tunnels belonging to a given routing instance. User equipment information is viewable from the properties form for individual WLAN GW tunnels. GTP session information (including bearer information) is viewable from the properties form for individual user equipment items. You can globally list WLAN GW tunnels from the Manage→ ISA Functions→ ISA-WLAN main menu.
Working with IGH objects
IGHs are navigation tree objects located below the device icon. IGHs are configured manually using the configuration forms available when you choose Create IGH from the IGH object navigation tree contextual menu.
You create an IGH to group together IP links and POS links so that if a configured number of links go out of service for any reason, the remaining links in the IGH go out of service too. This causes the routing protocols to re-converge to switch from the primary path to an alternate path.
The following requirements and restrictions apply to IGHs.
-
IGHs are supported only on SONET/TDM interfaces with PPP auto encapsulation.
-
A port or channel needs to be bound to a router interface after the member is added to an IGH.
Working with LAG objects
LAGs are navigation tree objects located below a device icon which aggregate multiple network connections in parallel to increase throughput beyond what a single connection can sustain, and to provide redundancy in case one of the links fails.
The following minimum configuration is required to enable LACP.
You must configure the following in the LAG configuration forms:
-
General properties, such as LAG description, configured address, encapsulation type, and administrative state
-
Link aggregation group parameters, such as port threshold, port threshold action, and dynamic cost
-
LACP parameters, such as LACP mode, LACP transmit interval, actor administration key, LACP transmission standby, and LACP selection criteria
-
LAG members, which are the compatible ports that can belong to a LAG
Because all ports can have their own MAC address, when ports are part of a LAG, the LAG must have an MAC address.
The port configuration of the first port added to the LAG is used to compare with subsequently added ports. If a discrepancy is found with a newly added port, that port is not added to the LAG.
The maximum number of ports you can add to or remove from a LAG is 64. The number of ports depends on the NE type; see the NE documentation for more information. All ports added to a LAG must have the same parameter settings.
Only ports belonging to one LAG subgroup are considered eligible members of a LAG and can be selected as active links.
A LAG can be configured with weighted per-link hashing, which allows a more balanced distribution of subscribers and services across LAG links. For example, significant differences in subscriber or SAP bandwidth requirements could lead to unbalanced traffic on LAG egress. You can configure each service or subscriber on a LAG with one of three unique classes and a weight value to distribute services and subscribers across LAG links.
A LAG can be configured with LAG adaptive load balancing to resolve a traffic imbalance between LAG member ports on the FP-based SR family of NEs. Adaptive load balancing monitors the traffic utilization of each LAG member port and identifies whether the traffic needs to be shifted toward certain ports based on a tolerance value. If the tolerance value is exceeded, the system identifies the best way to shift traffic to resolve this imbalance. Adaptive load balancing is mutually exclusive with per-link-hashing.
On supporting devices, you can enable LACP tunneling to transparently forward LACP packets. LACP tunneling is configured on Ethernet ports; see To configure Ethernet ports.
See OmniSwitch for OmniSwitch-specific LAG information.
See the NSP NFM-P Microwave Radio User Guide for Wavence-specific LAG information.
LAG link mapping profiles
You can use a LAG link mapping profile to assign a specific LAG egress port to a SAP or interface, and control how egress traffic is handled if the specified port fails. You can then configure the specified port to perform admission control and QoS contract with the knowledge that all traffic for the SAP or interface will egress on that port. You can also specify a secondary port to handle traffic in the event that the primary port fails. See To create a LAG link mapping profile for more information about creating LAG link mapping profiles.
LAG utilization TCAs
You can enable TCA on a LAG object and determine whether the LAG utilization value exceeds a TCA policy threshold. The following nodes support enabling TCA on LAG objects:
You can associate a TCA policy with a LAG object from the TCA policy configuration form. See To apply a TCA policy to objects using the object properties forms for information about applying an existing TCA policy to an object from the object properties form. The NFM-P compares the utilization value at each statistics collection to the threshold value in the TCA policy and raises an alarm when the LAG utilization value crosses the specified limit. You need to enable performance statistics collection on the LAG object to configure a TCA policy. See Chapter 19, TCA for more information about TCA.
L1 LAGs support collection of scheduled and on-demand statistics, and plotting of real-time and historical statistics. L2 and Ethernet LAGs support collection of scheduled statistics and plotting of historical statistics.
BFD on Ethernet LAGs
On supporting NEs, you can configure an Ethernet LAG to use BFD to speed up the detection of link failures. When BFD is enabled on a LAG, micro-BFD sessions are automatically created for each link in the group.
For information about configuring BFD on a LAG, see To modify a LAG . For information about viewing micro-BFD sessions on a LAG, see To view micro-BFD sessions on a LAG .