7

Strongly suggested: Configure both port-channel and its members identically (except of course for description and the channel-group and vpc bits). As long as an interface is not configured to be member of a LAG, or because LACP negotiation failed and the interface remains LACP individual [1], the configuration from the given (physical) interface applies, ...


7

What really happens is that any one flow only uses one of the links. Different flows are assigned to different links based on a hashing algorithm, so, in aggregate, you get the full bandwidth of the combined links, but any one flow will only get the bandwidth of a single link. You don't want to spread a single flow across multiple links because that will ...


7

As Ron Trunk pointed out, LACP uses a special multicast OUI on its frames. Your unmanaged switch does not recognize the OUI, only that it is multicast, and it sends the multicast frames to every other switch interface. LACP frames are sent with the special 01:80:c2:00:00:02 multicast MAC address. The IEEE has reserved the 01:80:c2 OUI for link protocols, and ...


6

I understand that this is an incorrect configuration, but what was blocking traffic to the new switch? Is this part of the port channel or spanning tree or something else? Nothing was actually "blocking" the traffic to the new switch, the traffic was simply being forwarded to the wrong switch. This is normal operation of ports that are part of a LAG. The ...


5

In most instances for hosts, no. Each interface is generally a separate network. Some hosts (usually servers) can use multiple (generally a maximum of eight) connections bonded together as a single virtual link, but there are some ways in which this could actually degrade performance. If you divide all the packets in a single network flow across multiple ...


5

How do I route the lacpdu packets through the unmanaged switch and make the etherchannel work? Etherchannel, LACP or a static LAG trunk can't work across an unmanaged switch ever. As both Rons have suggested you need either: a managed switch with an Etherchannel or an LACP trunk to each of the other switches a managed switch w/o LACP filtering (non-...


4

The whole point of MLAG / VPC is to have both link active, as in a standard link aggregation. Otherwise there would be little benefit over xSTP (spanning tree) (yes it converges faster but it's much more complex to setup and not interoperable between different brands). So if properly configured: when all links are up, you got the full bandwidth when a link ...


4

From this ARISTA manual, page 620: Static fallback: the port channel maintains one active port while in fallback mode; all its other memberports are in standby mode until a LACP PDU is received by the port channel. All member ports send(and can receive) LACP PDUs, but only the active port sends or receives data. Individual fallback: all member ports act as ...


4

SW3 is a switch. By first principle, portfast [trunk] or port type edge [trunk] should not be enabled on ports that connect to switches, lest you risk loops if that other switch connects to some other upstream switch. There are exceptions to this rule, but they require solid knowledge and understanding by the network admin. Usually, deployment of edge ...


4

You probably can't with a single switch. LACP frames are multicast, so the unmanaged switch will flood them out all ports. This will cause several problems: The sending switch will see its frame received on its other port. The switch will interpret this as a loop and refuse to aggregate the link. The receiving switch will see the same packet on both ...


4

Adding to Ron's excellent answer, with the vast majority of switches there are three different hashing algorithms: MAC address (L2), IP address (L3) and IP address plus port numbers (L4). The algorithm combines both source and destination addresses and mixes them together in its own special way (sometimes documented) to choose a somewhat random yet ...


4

We don't have router, all we have L2 switch network. We have many servers behind trunk, so should i use src-dsp-ip? or src-dst-mac ? You need to weigh several factors to determine which method to use in different places on your network. Different network engineers will come up with different recommendations. This is really leading to opinion-based answers,...


4

For routing protocols, “cost” might be better called “preference.” Presumably you would prefer higher bandwidth links, so they have lower cost.


3

That depends. If it is done correctly, each flow would get a maximum of 1 Gbps, but with multiple flows, you will be able to use the full 2 Gbps. Some people, on some equipment, can, and will, configure round-robin balancing, but that leads to problems like out-of-order packet delivery, which can completely kill real-time applications, and it can actually ...


3

You actually don't have to do anything. VPC paired Nexus work exactly as you want them to. The prerequisite is that all systems involved (i.e. the servers) are attached to the Nexus over a VPC enabled port channel of that given Nexus pair. https://community.cisco.com/t5/networking-documents/peer-gateway-feature-on-the-nexus-7000/ta-p/3113290 Please note: ...


3

In routing, cost is a measure for how much effort it takes to process and forward a packet or stream over a link or a path. As Ron has pointed out, this pretty much corresponds to the time the data occupies a link, therefore a higher data rate means less cost. (The worth may be the direct opposite. ;-) Depending on the perspective, metric may also be ...


2

That's not possible with PAgP. Traffic is always aggregated across the whole LAG trunk. Splitting the trunk in two groups of two ports plus spanning tree would work (switching over to the spare trunk when the default trunk's bandwidth decreases due to link loss), but when one physical link in each group fails you end up with two single links and one of them ...


2

Short answer: no. While the STP handover in step 4 or step 3 is usually faster than 1 second there's always a gap. Make sure you're using RSTP, MSTP or RPVST though. The original and largely obsolete STP is slow on convergence. One tiny thing might reduce the gap a little further: before step 3, decrease the trunk's STP priority value below that of the yet ...


1

You have a problem on Switch 1. Your default route is to an address that the switch doesn't know how to reach. The default route should be ip route 0.0.0.0/0 10.3.104.3. Switch 2 knows how to reach 172.16.64.1 because it is on a directly connected network, but Switch 1 doesn't know how to reach that network, so the next hop is Switch 2, not the router.


1

In TCP layer, it reads the port number from the packet, and find the application bind to this port number. TCP really doesn't look at the packets, and the packets do not contain port numbers. The TCP segment headers have the source and destination port numbers (TCP addresses). The IP packets have the source and destination IP addresses, but the TCP ...


1

Port-channeling is a way to bypass the topology limitation of spanning-tree allowed to only having a single path. In spanning tree, the logical topology of the data-plane will arrange itself into a logical tree where you can only have 1 active link between the same two devices. By implementing a LAG (link aggregation group: aka Port Channel) you fool ...


1

I'm sending data on multiple ports evenly, If your goal is to do round-robin load balancing, then I would highly discourage that because it leads to out-of-order data delivery that can actually slow things down. Your switches will balance flows across a channel not spread a single flow across multiple channel links. A single flow will use a single link. ...


1

Any single flow cannot exceed the bandwidth of a single member link within a port channel, so in your case, a single flow cannot go above 1 Gbps. If there are multiple flows between the two servers, you may be able to benefit from more than 1 Gbps, if you adjust the load balancing mechanism on the switches to take into account L4 port number (if supported). ...


1

I think you're misunderstanding port channels. Any one flow will still be capped at the speed of a single link in the channel. There is a hashing algorithm that decides which link a flow will use. With multiple flows, all the links will be used, so in aggregate, you can get the full bandwidth of the channel, but any one flow will be capped at the bandwidth ...


1

Based on your diagram, you cannot port channel. A port channel is between two devices. An port channel must start on one device, and terminate on another device. The port channel represents a single link between two devices that is actually comprised of multiple links. I don't think you really understand what a port channel does. It primarily fools spanning-...


1

Layer 3 connections don't use STP; STP is used for deploying redundant L2 links. Port-channels also require layer 2 links, so that won't work. Set up three routed links and use load balancing to distributed traffic. Load balancing can be done by IP addresses/ranges (easiest), services or actual link load (hardest). For each traffic group I'd set up one or ...


1

No, that is not a requirement. You have to ensure that they have same configuration (for instance: speed/duplex and other information).


Only top voted, non community-wiki answers of a minimum length are eligible