I have an issue on my router which is a CISCO2911. I keep getting duplex mismatch messages by the CDP which says the other end operates on half duplex.
But I cannot see any issue on the performance of the link. No packet loss, no CRC.
And my interface is configured with duplex auto, and it operates on Full duplex.
So it negotiates to Full with the connected device and that means it is also on auto negotiation because if it was hardcoded full then my interface would be on half.
And if the connected one was hardcoded half, then I would see CRC and this message. But there is no problem as I mentioned.
Also when I set the interface to fix full then it remains down.
The other device is a C2960 switch but I do not have access to it.
I know it would be "fixed" if I turned off the CDP on the interface but I would like to know the reason of this. Is it a bug?
%CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on GigabitEthernet0/1 (not half duplex), with XXXXXX FastEthernet0/10 (half duplex)
#sh cdp entry XXXXXX
Device ID: XXXXXX
Platform: cisco WS-C2960-48TT-L, Capabilities: Switch IGMP
Interface: GigabitEthernet0/1, Port ID (outgoing port): FastEthernet0/10
Holdtime : 134 sec
Cisco IOS Software, C2960 Software (C2960-LANBASEK9-M), Version 12.2(44)SE2, RELEASE SOFTWARE (fc2)
Copyright (c) 1986-2008 by Cisco Systems, Inc.
Compiled Thu 01-May-08 15:55 by XXXXXX
advertisement version: 2
Protocol Hello: OUI=0x00000C, Protocol ID=0x0112; payload len=27, value=00000000FFFFFFFF010220FF000000000000001F9DA9AF00FF0000
VTP Management Domain: ''
Native VLAN: 20
#sh int Gi0/1 | i Duplex|CRC
Full Duplex, 100Mbps, media type is RJ45
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
#sh run int Gi0/1 | i duplex
#sh ver | s C2900
Cisco IOS Software, C2900 Software (C2900-UNIVERSALK9-M), Version 15.2(4)M3, RELEASE SOFTWARE (fc2)
Try specifying your router to use CDPv2.
Upgrade the IOS on your 2960 switch to something like 12.2(55)SE9 or 15.0(2)SE4.
It is CDPv2 by default. It is the same without CDPv2 advertisements as well.
I have no access to the switch as I said but as soon as we find out who owns it we will try the upgrade.
I am suspecting the culprit is the switch. I've dealt with switches running very old IOS and when they connect up to another switch or a router, the switch will auto negotiate to half duplex. The "workaround" was to hard-code the speed and duplex.
Yes, but if the switch was on half duplex we should get CRCs on our end and the performance should be very bad. But I cannot see any problem regardless the messages.
I've found a similar IOS bug (about the switch's IOS); CSCeh35595
Check to ensure the switch doesn't have any q-in-q tunneling going on. If the other end of the l2tunnel has it's duplex out you'll see the message on this end as CDP is tunneled through the switch.
R2(HD)-----(FD) SW (FD)------R1(FD)
This is actually a WAN connection and the CDP should be tunneled all the way between the CE and PE routers. Also, the provider uses q-in-q as well. I do not have access to the switch.
But how can I see the switch in CDP when it is hidden by the tunnel?
The PE router has it's duplex as full for sure. So why do I see a duplex mismatch?
I doubt that anything was on half duplex on the way between the PE and CE. And if the l2tunnel is configured I shouldn't see the switch, right?
When I say WAN connection it means there is an MPLS connection. I have access to the CE and PE routers and nothing else. The PE router is a Juniper and it is connected to the provider's metro switch through a trunk link and each customer has it's own subinterface on the PE. And there is q-in-q between the PE and the metro switch. And there is q-in-q in the provider's network too.
I actually cannot tell you where the mentioned switch is but somewhere between the PE and CE.
And there should be l2tunneling all the way as the providers use it usually. So actually I should not see anything in the CDP table. But this switch is still there and I am getting the duplex mismatch message. But if something was on half duplex on the way we would have some issues with the performance on the link.
are you sure that interface is in full duplex mode because of auto-negotiation ? It seems me that GE port default is full duplex, so in case auto-negotiation fails operate in full duplex and 2911 has GE, isn't it ?
In any case if your interface is full duplex it will not experience collision because in full duplex the interface switches off the collision detection, collision will be detected on the half duplex interf
You are right, the interface which is on half duplex will get the late collisions. But the one which is on full duplex will get CRCs and packet loss will be visible on the connection (caused by collisions). However, there is no packet loss and no CRC.
By the way, the auto-negotiation process depends on the speed not the type of the interface:
"- If the speed is not known, use 10 Mbps, half duplex.
- If the speed is known to be 10 or 100 Mbps, default to use half duplex.
- If the speed is known to 1000 Mbps, default to use full duplex."
Of course, anything can happen when different type of devices are connected by different vendors but this is the IEEE standard.
And my interface has speed 100 which is hardcoded, not negotiated. So its duplex would be half when the negotiation fails.
I just had this issue on a Cisco 3750 stack connected to a juniper cluster.
The issue was cisco phones connected to the Juniper with the juniper set to 100 full duplex and the ip phones set to auto. The IP Phones correctly whined about the duplex mismatch over CDP but the Juniper just relayed that to the access layer switches which logged it as duplex mismatch against the uplink ports (2 x 1gb out of 4 x 1gb) while all the normal ports on the access switch are 100mb Fa's. It all looked wrong in the logs. Setting the IP Phone ports to auto, thereby removing the duplex mismatch stopped the duplex mismatch error messages over CDP.