Refer to the exhibit. The administrator troubleshoots an EtherChannel that keeps moving to err-disabled. Which two actions must be taken to resolve the issue?
(Choose two.)
Refer to the exhibit. The administrator troubleshoots an EtherChannel that keeps moving to err-disabled. Which two actions must be taken to resolve the issue?
(Choose two.)
To resolve the issue of EtherChannel moving to err-disabled, it is important to ensure compatibility and proper configuration on both switches involved in the EtherChannel. First, confirming that the switchport parameters of Port-channel1 match the parameters of the port channel on the neighboring switch (Option B) is crucial. This includes settings such as allowed VLANs, port modes, and encapsulation types. Secondly, it is essential to ensure that the neighbor interfaces of Gi1/0/2 and Gi1/0/3 are configured as members of the same EtherChannel (Option E). This prevents inconsistencies that could lead to misconfigurations and err-disable situations.
It's doesn't matter what port the neighbor switch use，neighbor switch can use 1/0/47 and 1/0/48 to bind in Po1 is OK，in the picture i don't see any neighbor switch config I'm going for B/C
We can decide with exclude method: A = Wrong answer Group number is local to each switch B = Correct answer because we should make sure that parameters are correct C = Correct answer We also need to make sure that our interfaces trace to the same switch D = Wrong answer No way to reboot the switch and solve the issue. E = Wrong answer We do not care which interfaces we have on the neighboring device so C is not correct in my opinion.
Read again 'E': "Ensure that the neighbor interfaces of Gi1/0/2 and Gi1/0/3" This is about the local int NOT the opposite side. So B and E is correct.
E is about having no matter which ports on remote device but in same Po
B and E. Keep in mind that c3650 switches are stackable switches, so you could easily have 6 switch members stacked and having the port-channel interfaces going to any of those switches. Option C is definitely not an issue in this scenario.
Its another terrible question. If you go but what is shown on the screen the output is a CAT3650, not a Nexus. BUT, 3650s are stackable too, also allowing the etherchannel to connect to different switches. So also going with BE.
Err disable state is due to misconfig of etherchannels or ports on both switches. https://community.cisco.com/t5/networking-knowledge-base/port-status-is-errdisable-due-to-etherchannel-misconfiguration/ta-p/3131226#:~:text=The%20errdisable%20status%20indicates%20that,issue%20the%20show%20port%20command.
I think B and E are the correct answer. The C seems correct but the only case you can connect an etherchannel in different phisical equipments is that the equipments are StackWise o VSS connected.
The problem with E is we don't know whether neighboring switch uses ports Gi1/0/2 and Gi1/0/3. We only have this information of the local switch. Which makes E answer as bad as C.
"... neighbor interface of Gi1/0/2 and Gi1/0/3... " does not refer to Gi1/0/2 and Gi1/0/3 on the other switch. This can be any port numbers.
same neighboring switch is not a requirement (e.g.: ACI Leaf with vPC) BE is correct
The err-disable status indicates tha the port was automatically disabled by the switch operating system software because of an error condition encountered on the port.
"Ensure that the neighbor interfaces of Gi1/0/2 and Gi1/0/3" I think refers to the whatever interfaces are on the other side of the etherchannel from Gi1/0/2 and Gi1/0/3. B and E are correct to me.
Here is what we know: 1)Interfaces on local switch are g1/0/2 and g1/0/3, and are bundled into port-channel 1 2) They are in err-disabled Now, we have no information on the neighbor switch, and we need to deduce the correct answer based on the options available and the given information. A) Port-channels do not require matching port-channel id on the neighbor device, so this is wrong B) Port-channel parameters do need to be compatible, meaning, we need to have compatible protocols and modes on both sides of the port-channel, e.i. PAGP = auto/desirable, LACP= active/passive, static=ON C) This isn't entirely necessary, as you could have a StackWise setup of switches, in this case you can connect to different switches, same goes for vPC or VSS architecture D) No. E) We do need to ensure that the neighboring switch has their interfaces in the port-channel connecting to the local switch From this we can confidently conclude that B and E are the right answers. The only reason C isn't correct is because we do not know where it is only connecting to one switch or if its using StackWise/VSS/vPC
I would choose B and E.
B & E are correct .......................
Tried to lab it, none of C or E worked for me. The error received is: *Feb 16 09:55:09.654: %EC-5-DONTBNDL: Et0/1 suspended: incompatible remote port with Ethernet0/0 in both cases.
We all agree that B is correct. My concern is the err-disable state. I have seen an ether-channel come up when not all neighboring ports are configured for the same ether-channel. One of the main purposes of ether-channel is redundancy, meaning you do not have to have all links up for the ether-channel to come up. I have also seen ether-channel misconfigurations where ports connected to different switches. This scenario will bring the etherchannel up to one switch with the other port Down, standalone or suspended. I have never seen a etherchannel fail to come up if at least one port was properly configured to the other device.
B and C
I have labbed this in CML. The answer is indeed E. I receive the same exact errors when i put two of the neighbor interfaces in different port-channel group, either 1/2 and 1/no-group