Cisco etherchannel windows 2003

With the above switch and NICs, they have teamed two cards on each server 3 servers total for the domain network communication. There is no problem with the NIC teams, they are functioning fine, I have tested failover of each unplug one of the cords. The contractor has not done this, and although everything is working fine, I want to get the top performance and reliability of this buildout. Is the link currently saturated? If not, then configuring Etherchannel is not likely to do anything for you.

More likely than not the teams are using LACP for increased throughput and failover. If this is the case manually creating an EtherChannel is redundant and will lock the port group into specific manually configured ports rather than LACP's dynamic assignment of ports.

You should probably verify that the NIC teams are configured for LACP if they're not it may be for good reason, don't change it if you don't understand the reasons it was setup the way it is.

Well yes, setting up two NICs in a team only gives you failover redundancy, if it's done using an LACP-capable stack then etherchanneling on the switch allows you to, theoretically at least, double your bandwidth. Sign up to join this community. The best answers are voted up and rise to the top. Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams?

Learn more. Asked 10 years, 7 months ago. Active 10 years, 3 months ago. Viewed 6k times. To use this mode, you generally need to enable LACP manually on the port of the switch. You can add more NIC to the Team as per your need and requirement of the scenario. In network properties, we can see the NIC Team icon and its speed showing as 2. At this point we have complete the configuration involved in NIC Teaming, this is time to configure the Cisco Switch side so that both sides can be synchronized.

If you have Switch access, you should know about the connected ports of your Server so that you can configure the same LACP port-channel in switch side. This design will also provide us Switch level redundancy. After login into the Switch simply paste these commands in a switch and save the configuration. When a new control unit is elected, you must reestablish the VPN connections. When you connect a VPN tunnel to a Spanned interface address, connections are automatically forwarded to the control unit.

When you combine multiple units into a cluster, you can expect the total cluster performance to be approximately:. For example, for TCP throughput, the Firepower with 3 SM modules can handle approximately Gbps of real world firewall traffic when running alone. Members of the cluster communicate over the cluster control link to elect a control unit as follows:. When you deploy the cluster, each unit broadcasts an election request every 3 seconds.

Any other units with a higher priority respond to the election request; the priority is set when you deploy the cluster and is not configurable.

If after 45 seconds, a unit does not receive a response from another unit with a higher priority, then it becomes the control unit. If multiple units tie for the highest priority, the cluster unit name and then the serial number is used to determine the control unit. If a unit later joins the cluster with a higher priority, it does not automatically become the control unit; the existing control unit always remains as the control unit unless it stops responding, at which point a new control unit is elected.

In a "split brain" scenario when there are temporarily multiple control units, then the unit with highest priority retains the role while the other units return to data unit roles. You can manually force a unit to become the control unit.

For centralized features, if you force a control unit change, then all connections are dropped, and you have to re-establish the connections on the new control unit. Clustering provides high availability by monitoring chassis, unit, and interface health and by replicating connection states between units.

Chassis-application health monitoring is always enabled. If the Firepower Threat Defense device cannot communicate with the supervisor, it removes itself from the cluster. Each unit periodically sends a broadcast keepalive heartbeat packet over the cluster control link. If the control unit does not receive any keepalive heartbeat packets or other packets from a data unit within the timeout period, then the control unit removes the data unit from the cluster.

If the data units do not receive packets from the control unit, then a new control unit is elected from the remaining members. If units cannot reach each other over the cluster control link because of a network failure and not because a unit has actually failed, then the cluster may go into a "split brain" scenario where isolated data units will elect their own control units.

For example, if a router fails between two cluster locations, then the original control unit at location 1 will remove the location 2 data units from the cluster.

Meanwhile, the units at location 2 will elect their own control unit and form their own cluster. Note that asymmetric traffic may fail in this scenario. See Control Unit Election for more information. Each unit monitors the link status of all hardware interfaces in use, and reports status changes to the control unit. Each chassis monitors the link status and the cLACP protocol messages to determine if the port is still active in the EtherChannel, and informs the Firepower Threat Defense application if the interface is down.

A ll physical interfaces are monitored by default including the main EtherChannel for EtherChannel interfaces. Only named interfaces that are in an Up state can be monitored.

For example, all member ports of an EtherChannel must fail before a named EtherChannel is removed from the cluster. If a monitored interface fails on a particular unit, but it is active on other units, then the unit is removed from the cluster. The amount of time before the Firepower Threat Defense device removes a member from the cluster depends on whether the unit is an established member or is joining the cluster.

The Firepower Threat Defense device does not monitor interfaces for the first 90 seconds that a unit joins the cluster. Interface status changes during this time will not cause the Firepower Threat Defense device to be removed from the cluster.

For an established member, the unit is removed after ms. For inter-chassis clustering, if you add or delete an EtherChannel from the cluster, interface health-monitoring is suspended for 95 seconds to ensure that you have time to make the changes on each chassis. When you install a decorator application on an interface, such as the Radware DefensePro application, then both the Firepower Threat Defense device and the decorator application must be operational to remain in the cluster.

The unit does not join the cluster until both applications are operational. Once in the cluster, the unit monitors the decorator application health every 3 seconds.

If the decorator application is down, the unit is removed from the cluster. When a node in the cluster fails, the connections hosted by that node are seamlessly transferred to other nodes; state information for traffic flows is shared over the control node's cluster control link. If the control node fails, then another member of the cluster with the highest priority lowest number becomes the control node.

The FTD automatically tries to rejoin the cluster, depending on the failure event. After a cluster member is removed from the cluster, how it can rejoin the cluster depends on why it was removed:. Failed cluster control link when initially joining—After you resolve the problem with the cluster control link, you must manually rejoin the cluster by re-enabling clustering.

Failed cluster control link after joining the cluster—The FTD automatically tries to rejoin every 5 minutes, indefinitely. Failed data interface—The FTD automatically tries to rejoin at 5 minutes, then at 10 minutes, and finally at 20 minutes. If the join is not successful after 20 minutes, then the FTD application disables clustering.

After you resolve the problem with the data interface, you have to manually enable clustering. Failed unit—If the unit was removed from the cluster because of a unit health check failure, then rejoining the cluster depends on the source of the failure. For example, a temporary power failure means the unit will rejoin the cluster when it starts up again as long as the cluster control link is up. The FTD application attempts to rejoin the cluster every 5 seconds.

Failed Chassis-Application Communication—When the FTD application detects that the chassis-application health has recovered, it tries to rejoin the cluster automatically.

Internal error—Internal failures include: application sync timeout; inconsistent application statuses; and so on. Failed configuration deployment—If you deploy a new configuration from FMC, and the deployment fails on some cluster members but succeeds on others, then the units that failed are removed from the cluster. You must manually rejoin the cluster by re-enabling clustering.

If the deployment fails on the control unit, then the deployment is rolled back, and no members are removed. If the deployment fails on all data units, then the deployment is rolled back, and no members are removed. Every connection has one owner and at least one backup owner in the cluster.

The backup owner is usually also the director. See the following table for clustering support or lack of support for this kind of traffic. Connections can be load-balanced to multiple members of the cluster.

Connection roles determine how connections are handled in both normal operation and in a high availability situation. Owner—Usually, the node that initially receives the connection. The owner maintains the TCP state and processes packets. A connection has only one owner. If the original owner fails, then when new nodes receive packets from the connection, the director chooses a new owner from those nodes.

The backup owner does not take over the connection in the event of a failure. If the owner becomes unavailable, then the first node to receive packets from the connection based on load balancing contacts the backup owner for the relevant state information so it can become the new owner. As long as the director see below is not the same node as the owner, then the director is also the backup owner.

If the owner chooses itself as the director, then a separate backup owner is chosen. For clustering on the Firepower , which can include up to 3 cluster nodes in one chassis, if the backup owner is on the same chassis as the owner, then an additional backup owner will be chosen from another chassis to protect flows from a chassis failure. Director—The node that handles owner lookup requests from forwarders. If packets arrive at any node other than the owner, the node queries the director about which node is the owner so it can forward the packets.

A connection has only one director. If a director fails, the owner chooses a new director. As long as the director is not the same node as the owner, then the director is also the backup owner see above.

Forwarder—A node that forwards packets to the owner. If a forwarder receives a packet for a connection it does not own, it queries the director for the owner, and then establishes a flow to the owner for any other packets it receives for this connection. The director can also be a forwarder. For short-lived flows such as DNS and ICMP, instead of querying, the forwarder immediately sends the packet to the director, which then sends them to the owner.

A connection can have multiple forwarders; the most efficient throughput is achieved by a good load-balancing method where there are no forwarders and all packets of a connection are received by the owner.

We do not recommend disabling TCP sequence randomization when using clustering. Fragment Owner—For fragmented packets, cluster nodes that receive a fragment determine a fragment owner using a hash of the fragment source IP address, destination IP address, and the packet ID.

All fragments are then forwarded to the fragment owner over the cluster control link. Fragments may be load-balanced to different cluster nodes, because only the first fragment includes the 5-tuple used in the switch load balance hash. Other fragments do not contain the source and destination ports and may be load-balanced to other cluster nodes. If it is a new connection, the fragment owner will register to be the connection owner. If it is an existing connection, the fragment owner forwards all fragments to the provided connection owner over the cluster control link.

The connection owner will then reassemble all fragments. When a new connection is directed to a member of the cluster via load balancing, that unit owns both directions of the connection. If any connection packets arrive at a different unit, they are forwarded to the owner unit over the cluster control link.

If a reverse flow arrives at a different unit, it is redirected back to the original unit. The following example shows the establishment of a new connection. The SYN packet originates from the client and is delivered to one FTD based on the load balancing method , which becomes the owner.

The owner creates a flow, encodes owner information into a SYN cookie, and forwards the packet to the server. This FTD is the forwarder. Because the forwarder does not own the connection, it decodes owner information from the SYN cookie, creates a forwarding flow to the owner, and forwards the SYN-ACK to the owner.

The director receives the state update from the owner, creates a flow to the owner, and records the TCP state information as well as the owner. The director acts as the backup owner for the connection.

Any subsequent packets delivered to the forwarder will be forwarded to the owner. If packets are delivered to any additional nodes, it will query the director for the owner and establish a flow.

Any state change for the flow results in a state update from the owner to the director. The director finds no existing flow, creates a director flow and forwards the packet back to the previous node. In other words, the director has elected an owner for this flow.

The owner creates the flow, sends a state update to the director, and forwards the packet to the server. The second UDP packet originates from the server and is delivered to the forwarder. The forwarder queries the director for ownership information.

For short-lived flows such as DNS, instead of querying, the forwarder immediately sends the packet to the director, which then sends it to the owner. The forwarder creates a forwarding flow to record owner information and forwards the packet to the owner. Cluster deployment for Snort changes completes faster, and fails faster when there is an event.

Cluster deployment for Snort changes now completes faster. Also, when a cluster has an event that causes an FMC deployment to fail, the failure now occurs more quickly. FMC has improved cluster management functionality that formerly you could only accomplish using the CLI, including:. Show cluster status from the Device Management page, including History and Summary per unit.

You can now create a cluster using container instances. On the Firepower , you must include one container instance on each module in the cluster. We recommend that you use the same security module or chassis model for each cluster instance. The control unit now syncs configuration changes with data units in parallel by default.

Formerly, synching occurred sequentially. Messages for cluster join failure or eviction added to show cluster history. New messages were added to the show cluster history command for when a cluster unit either fails to join the cluster or leaves the cluster. If you enable Dead Connection Detection DCD , you can use the show conn detail command to get information about the initiator and responder. Dead Connection Detection allows you to maintain an inactive connection, and the show conn output tells you how often the endpoints have been probed.

In addition, DCD is now supported in a cluster. You can now add any unit of a cluster to the Firepower Management Center, and the other cluster units are detected automatically. Formerly, you had to add each cluster unit as a separate device, and then group them into a cluster in the Management Center.

Adding a cluster unit is also now automatic. Note that you must delete a unit manually. You can now configure site-to-site VPN with clustering. Formerly, many internal error conditions caused a cluster unit to be removed from the cluster, and you were required to manually rejoin the cluster after resolving the issue. Now, a unit will attempt to rejoin the cluster automatically at the following intervals: 5 minutes, 10 minutes, and then 20 minutes.

Internal failures include: application sync timeout; inconsistent application statuses; and so on. With FXOS 2. For the Firepower , you can include up to 6 modules. For the Firepower , you can include up to 6 chassis.

Inter-site clustering is also supported. However, customizations to enhance redundancy and stability, such as site-specific MAC and IP addresses, director localization , site redundancy , and cluster flow mobility, are only configurable using the FlexConfig feature. Intra-chassis Clustering for the Firepower You can cluster up to 3 security modules within the Firepower chassis. All modules in the chassis must belong to the cluster.

Skip to content Skip to search Skip to footer. Book Contents Book Contents. Find Matches in This Book. PDF - Complete Book Updated: December 7, Note Some features are not supported when using clustering. Note Individual interfaces are not supported, with the exception of a management interface.

Assigns a management interface to all units in the cluster. Cluster Members Cluster members work together to accomplish the sharing of the security policy and traffic flows. Cluster Control Link For native instance clustering: The cluster control link is automatically created using the Port-channel 48 interface. For example: NAT results in poor load balancing of connections, and the need to rebalance all returning traffic to the correct units.

Note If your cluster has large amounts of asymmetric rebalanced traffic, then you should increase the cluster control link size. Management Network We recommend connecting all units to a single management network. Management Interface You must assign a Management type interface to the cluster. Cluster Interfaces For intra-chassis clustering, you can assign both physical interfaces or EtherChannels also known as port channels to the cluster. Spanned EtherChannels Spanned EtherChannels You can group one or more interfaces per chassis into an EtherChannel that spans all chassis in the cluster.

Configuration Replication All nodes in the cluster share a single configuration. Licenses for Clustering You assign licenses to the cluster as a whole, not to individual nodes. Note If you add the cluster before the FMC is licensed and running in Evaluation mode , then when you license the FMC , you can experience traffic disruption when you deploy policy changes to the cluster. Maximum 6 nodes—You can use up to six container instances in a cluster.

Clustering Guidelines and Limitations Switches for Inter-Chassis Clustering Make sure connected switches match the MTU for both cluster data interfaces and the cluster control link interface. To avoid asymmetric traffic in a VSS design, change the hash algorithm on the port-channel connected to the cluster device to fixed: router config port-channel id hash-distribution fixed Do not change the algorithm globally; you may want to take advantage of the adaptive algorithm for the VSS peer link.

Defaults The cluster health check feature is enabled by default with the holdtime of 3 seconds. Connection replication delay of 5 seconds is enabled by default for HTTP traffic. Before you begin Download the application image you want to use for the logical device from Cisco. For inter-chassis clustering, add the same Management interface on each chassis.

For inter-chassis clustering, add the same eventing interface on each chassis. Step 2 Choose Logical Devices. Native Cluster Figure 2. Choose the Image Version. You see the Provisioning - device name window. Step 4 Choose the interfaces you want to assign to this cluster.

Step 5 Click the device icon in the center of the screen. Step 6 On the Cluster Information page, complete the following. Figure 3. Native Cluster Figure 4. Multi-Instance Cluster Container Instance for the Firepower only In the Security Module SM and Resource Profile Selection area, you can set a different resource profile per module; for example, if you are using different security module types, and you want to use more CPUs on a lower-end model.

Choose the Management Interface. Step 7 On the Settings page, complete the following. Step 8 On the Interface Information page, configure a management IP address for each security module in the cluster. Note You must set the IP address for all 3 module slots in a chassis, even if you do not have a module installed.

Specify a unique IP address on the same network for each module. Enter a Network Gateway address. Step 10 Click OK to close the configuration dialog box. Step 11 Click Save. Step 12 For inter-chassis clustering, add the next chassis to the cluster: On the first chassis Firepower Chassis Manager , click the Show Configuration icon at the top right; copy the displayed cluster configuration.

The cluster information is mostly pre-filled, but you must change the following settings: Chassis ID —Enter a unique chassis ID. Note The FXOS steps in this procedure only apply to adding a new chassis ; if you are adding a new module to a Firepower where clustering is already enabled, the module will be added automatically.

Before you begin In the case of a replacement, you must delete the old cluster node from the FMC. Note If you only applied a patch release, you can skip this step. On the new chassis, make sure the new image package is installed. Step 3 Click the Show Configuration icon at the top right; copy the displayed cluster configuration.

Step 5 For the Device Name , provide a name for the logical device. Step 6 C lick OK. Step 8 Click the device icon in the center of the screen.

Step 9 Click Save. Choose licenses to apply to the device. A unit that is currently registering shows the loading icon. Step 2 Configure device-specific settings by clicking the Edit for the cluster. The switch chooses the link on the basis of the destination or source MAC address of the frame. The default is to use the source MAC address.

This default means that all packets that the switch receives on a non-Fast EtherChannel port with the same MAC source address that have a destination of the MAC addresses on the other side of the channel take the same link in the channel.

The use of source-based forwarding in this situation evenly distributes traffic across all links in the channel. EtherChannel balances the traffic load across the links in a channel through the reduction of part of the binary pattern that the addresses in the frame form to a numerical value that selects one of the links in the channel. EtherChannel load balancing can use MAC addresses or IP addresses, source or destination addresses, or both source and destination addresses.

The mode applies to all EtherChannels that are configured on the switch. You can find out which interface is used in the EtherChannel to forward traffic based on the load balancing method. The number of EtherChannels has the limit of six with eight ports per EtherChannel. The Catalyst series switches support both Layer 2 and Layer 3 EtherChannel, with up to eight compatibly configured Ethernet interfaces.

The limit of the number of EtherChannels is the number of ports of the same type. With source-MAC address forwarding, when packets are forwarded to an EtherChannel, the packets are distributed across the ports in the channel based on the source-MAC address of the incoming packet. Therefore, to provide load balancing, packets from different hosts use different ports in the channel, but packets from the same host use the same port in the channel. With destination-MAC address forwarding, when packets are forwarded to an EtherChannel, the packets are distributed across the ports in the channel based on the destination host MAC address of the incoming packet.

Therefore, packets to the same destination are forwarded over the same port, and packets to a different destination are sent on a different port in the channel. For the series switch, when source-MAC address forwarding is used, load distribution based on the source and destination IP address is also enabled for routed IP traffic. All routed IP traffic chooses a port based on the source and destination IP address.

Packets between two IP hosts always use the same port in the channel, and traffic between any other pair of hosts can use a different port in the channel. The default port can be identified from the output of the command show etherchannel summary by a notation of d. With the enablement of PAgP, the two possible methods of link determination are preserve order and maximize load balancing between the links on the Fast EtherChannel.

The default is to maximize load balancing. PAgP is used to negotiate the configured method with the device at the other side of the channel. This provides the maximum possible load-balancing configuration. When Fast EtherChannel is configured with PAgP disabled, the switch cannot negotiate with the partner about the switch learning capability.

Whether the switch preserves frame ordering depends on whether the Fast EtherChannel partner performs source-based distribution. The active port is used for flooded traffic such as unknown unicast, unregistered multicast, and broadcast packets. If the port-channel mode is on PAgP disabled , the active port is the link with the highest priority value. If the mode is desirable or auto PAgP enabled , the active port is selected based on the priority of the links on the switch that has the higher Ethernet address.

When two ports on the switch with the higher Ethernet address have the same priority, the port with the lower ifIndex is selected. When one link fails, all traffic that previously used that link now uses the link next to it. For example, if Link 1 fails in a bundle, traffic that previously used Link 1 before the failure now uses Link 2. PAgP aids in the automatic creation of EtherChannel links. PAgP packets are sent between EtherChannel-capable ports in order to negotiate the formation of a channel.

Some restrictions are deliberately introduced into PAgP.