I just would like to add some complementary tips (not for Lazaros, I’m sure that he knows, but for other people which may be trying to learn more):
1: Checking for input errors is not only relevant for fiber optics. It’s very useful for all Ethernet (both fiber and copper) and even for WiFi connectivity.
Check for “input errors” (total), then drill down for more specific counters. For instance, when using Ethernet 1 Gbps Cat5e cables, if there is a source of electrical interference nearby, you may see some CRC errors. In Wifi, collisions may happen.
2: Specifically for fiber optics, sometimes it’s worth to compare the light levels (TX/RX) at both ends
They will not match (light signal power received will be lower than the transmitted, of course - the dB logarithm notation is used). But if the light signal reduction (transition loss) is higher than the expected, and the received light signal power is too low, something may be wrong with the optical cable or SFP modules.
Also, although not the goal of this lesson, but be aware that comparing transmitted vs. received signal power is very useful for radio-based (WiFi and WiMax) troubleshooting as well.
Can you let me know what command should we use to change the mac address and set into new mac address instead of disabling the port security with the second example
In the second example, another solution to the problem would be to change the MAC address that is configured as part of the port security rather than disabling port security altogether. This can be done using the
Couldn’t we simply solve the speed and duplex mismatch issues if we would:
manually set (i.e. hard code) all interfaces’ duplex settings to full, and
set the speed on all interfaces to auto?
As for point 1: our other options are setting it to auto, or half-duplex. Half-duplex is always unnecessary, unless we know for sure that a hub connects to the given port (more often than not, this shouldn’t be the case). And auto is bad because if the (cisco) switch senses a speed of 10 or 100 Mbits/sec from the other end, it (the switch that senses the speed of 10 or 100 Mbits/sec) will automatically set its duplex settings to half-duplex. Which is bad.
As for point 2: our other options are hard coding the speed. If the speed on both ends of the links is the same, then we’re lucky, but if it’s not, then there’s a speed mismatch. Which is bad.
Couldn’t we solve all speed and duplex-related problems with this configuration of hard coded full duplex and speed setting of auto?
Another question: Wendell Odom’s book, the Official Cert Guide, aka OCG (on page 219 in the PDF, or Volume 1, Chapter 7, page 161) explicitly states the above behavior about switches. I can see no explicit statement that this behavior is true for routers as well. Is this how routers operate as well? I.e. if the router is configured with auto/auto speed and duplex settings, and it senses a speed of 10 or 100 Mbits/sec, it sets its duplex settings to half-duplex?
Typically, the best practice in today’s networking environment is to leave the duplex and speed settings at their default. This is especially true if you are using the same vendor for your networking equipment across your whole network.
Concerning duplex settings, they are only meaningful for Ethernet and FastEthernet (10 and 100 Mbps, respectively), and even then, they should negotiate to full duplex since both technologies are capable of that. Only under special circumstances should you change it, such as when connecting devices that don’t support full duplex or don’t support auto-negotiation.
Concerning the speed, I would also not recommend changing the default because, on a large network, there are often cases when a device will be capable of FastEthernet only and will need to be specially accommodated to get it to work. It’s adding one more step to resolve issues that would not exist if the default was kept.
Working on large networks with thousands of access ports, with the duplex and speed configs set to their defaults, I have never come across a problem with duplex or speed mismatches. If you have a consistency of vendor throughout, it is even more unlikely you will ever come across it. So it is best in my opinion to leave it as it is, and any rare problems that may occur due to old equipment or unsupported auto-negotiation can be dealt with on a case-by-case basis.
The point of the lesson is to ensure that we understand the concepts involved with speed and duplex settings.
As for routers, the behavior is the same as far as duplex and speed settings on the interfaces go.
The reason why I’m concerned about leaving both settings at their defaults is because when your devices are on default settings (which means they have autonegotiation enabled) and the other party has theirs hard coded to 10/full or 100/full (like in the case where your router connect to the ISP’s router), your Cisco devices will automatically change to 10/half or 100/half, respectively (or 10/half if the speed can’t be sensed at all and that’s the slowest possible speed). The point being that if your device doesn’t sense 1 Gbps (i.e. 1000 Mbps) or higher, it’ll default to half-duplex. Of course we know that half-duplex is only necessary when you’re connected to hubs (also routers always speak full-duplex), so wouldn’t it be the case that the settings I’ve recommended would fix these issues and lead to no new ones? Or at the very least avoid any nodes sending at half-duplex?
So if you set everything to full-duplex, then there won’t be any duplex issues (since no hubs are used anymore). And I just realized a possible mistake in my line of thought: if you set your speed to auto, then your device may not sense the other device’s hard-coded speed, so your device will default to its lowest available speed. So I guess I should revise my idea and say that you should for sure hard-code the duplex settings to full - but I’m not sure how often it happens that the speed isn’t senses correctly. But based on what you said above, the speed can be left at autonegotiation, since it doesn’t really happen that the speed isn’t sensed. So my original recommendation, in light of this, seems to be correct, unless I’ve missed something. However, as you can tell, I’m not very sure about this speed part.
I’m basing this on page 160 of Wendell Odom’s Volume 1 Official Cert Guide (OCG), or 218 if you’re using the PDF. I might be misinterpreting what he says, but it seems to me that what he’s saying is that if one switch has autonegotiation enabled, and the other one has the speed and duplex settings hard-coded in the way I described, unwanted behavior can occur. And problems can be avoided by implementing the settings I described - however, I’m not certain about this, which is why I’m asking for other opinions as well.
Thank you very much for the correspondence, I’m learning a lot!
Just to clarify, you are referring to the rule in the Ethernet standard that says that if a device with autonegotiation enabled is connected to a device that has its speed and duplex manually configure, the autonegotiation cannot correctly determine the speed and duplex settings of the other device. As a result, it will default to half-duplex mode and to the lowest supported speed (10Mbps) to avoid potential collisions and to ensure connectivity is established. However, as you correctly stated, this is definitely undesirable!
However, I would not resort to manually configuring all of my interfaces with speed and duplex settings. The administrative overhead needed to do this is not worth the effort. It is rare that you would come across such a situation, however, if you did, you should have an NMS system that will detect it. Once detected, you would rectify it and all is well. This is a much cleaner and less labor-intensive solution in practice. Does that make sense?
HDLC and PPP are both Data Link layer protocols used in computer networks. While they share some similarities, they also have notable differences. Here are some of the highlights of their similarities and their differences.
Similarities
Layer Functionality: Both HDLC and PPP operate at the data link layer of the OSI model and are used for encapsulating data for transmission over a physical network.
Frame Structure: They both use a frame structure for encapsulation of network layer data, with fields for addressing, control information, data, and error checking.
Error Detection: Both protocols include mechanisms for error detection, typically using a frame check sequence (FCS) at the end of each frame.
Link Establishment: They are used to establish and maintain links between two points in a network.
Differences
Standardization and Flexibility:
HDLC: It is an ISO standard (ISO 13239) and is less flexible. It’s typically used in fixed configurations and doesn’t allow for much negotiation of options.
PPP: It is more flexible and configurable, with support for various options like authentication, compression, and multilink connections. PPP can adapt to a wider range of transmission mediums and requirements.
Authentication:
HDLC: Does not include built-in support for authentication.
PPP: Supports authentication protocols such as PAP (Password Authentication Protocol) and CHAP (Challenge Handshake Authentication Protocol).
Protocol Support:
HDLC: Primarily designed for use in synchronous serial data links and is often used in WANs. It is less versatile in supporting different network layer protocols.
PPP: Designed to encapsulate multiple network layer protocols over the same link, making it more versatile for internet and broadband applications.
Use Cases:
HDLC: Commonly used in situations where a reliable, point-to-point or point-to-multipoint connection is needed, such as in leased lines and circuit-switched connections.
PPP: Widely used for dial-up internet connections, DSL connections, and other scenarios requiring a point-to-point connection over various physical mediums, including telephone lines, fiber optics, and radio links.
Modes of Operation:
HDLC: Can operate in several modes, including Normal Response Mode (NRM), Asynchronous Balanced Mode (ABM), and Asynchronous Response Mode (ARM).
PPP: Primarily operates in a simple point-to-point mode.
Addressing:
HDLC: Supports addressing, which allows it to be used in multi-point networks.
PPP: Typically does not use addressing as it is primarily used in point-to-point connections.
While HDLC is more rigid and suitable for traditional, fixed network setups often found in WAN environments, PPP is more adaptable, supporting a wide range of network types and options. This adaptability makes PPP more suitable for the diverse requirements of modern internet connectivity, including dial-up, DSL, and broadband connections.
For more information about each technology, take a look at these NetworkLessons notes:
