hi kids, this is your dad, huahuanjayy wkwkwk, Nuenomaru the handsome is back in action.
Okay, this tutorial article is very useful as a basic guide to handling common network issues that occur when your provider covers an apartment area where there is more than one broadband internet service provider. The most basic network problem usually happens during activation, when a provider’s technician plugs in all the available LAN cables inside the customer’s unit. Meanwhile, one of those LAN cables is still connected on the panel side to an active switch port. As a result, the switch in the panel indirectly receives broadcast traffic from the newly installed device of another provider.
Ideally, when a customer is no longer subscribed, the corresponding switch port in the panel should be shut down. However, if this situation has already occurred, let’s continue using the most basic troubleshooting approach so we can build a clear logical process in resolving the network issue.
The customer in Unit XXX, West Wing, is no longer subscribed. However, the UTP cable going to the panel has not been dismantled.
This is to make it easier in case the customer decides to subscribe again in the future, so there will be no need to pull a new UTP cable from the panel to the customer’s unit (which also helps reduce installation costs charged by the apartment management).
** before we continue, I would like to remind you that this is one of the most basic methods, but it is not efficient. I am writing this method solely for the purpose of building a smoother analytical process such as performing MAC tracing, executing switch commands, and manually handling broadcast traffic within the network.
First, the user may complain that the internet package they subscribed to does not match the expected performance. After checking via Speedtest and WhatsMyIP, it is detected that the device is obtaining a DHCP IP address from a different broadband provider, not from the ISP the user subscribed to just like a typical retail customer who would immediately file a hard complaint with customer service. Then a technician is dispatched to visit the unit. Here are several steps you can take:
1 Check the Gateway
When the technician is on site, connect a laptop or smartphone to the customer’s unit network, either via Wi-Fi or LAN cable.
Once connected, immediately open the IP gateway address in a browser to access the login page of the provider’s device that is broadcasting the signal. If you are able to log in to the device (most broadband ISP default usernames and passwords can usually be found on Google), check the MAC address of that device.
In this case, the customer subscribes to broadband internet from an ISP called Nue. However, when the technician checks on site, the customer is receiving a DHCP broadband IP address from a different provider.
2 arp -a
If you are unable to access the gateway of the device that is broadcasting, open Command Prompt (CMD) on the technician’s laptop at the site. Type arp -a to view the MAC addresses of devices on the connected network. Once the list of MAC addresses appears, copy and identify the MAC address by checking it on https://macvendors.com/
If it is identified as a device brand that is not part of your infrastructure, immediately trace it and shut down the corresponding port. However, keep in mind that the arp -a command only displays devices on the network that have previously communicated with your laptop.
3 Trace the Full Layer 2 Network Infrastructure
If all previous methods fail, we move to the most fundamental approach. The technician should perform a direct bypass test to the Layer 2 switch in the panel (the ISP internet source), connecting the switch directly to the laptop. Then, the Layer 2 team will run the `show mac` command and check whether any switch port is carrying more than two MAC addresses on a single port. If such a port is found, proceed to shut it down. Meanwhile, the field technician should verify whether the laptop is still obtaining a DHCP IP address from a different provider.
This method focuses on identifying MAC addresses and shutting down ports one by one to ensure that there is no more than one broadcast source and that the unwanted broadcast is completely eliminated from the network.
4 Default Native VLAN 1
This step is an initial mitigation to prevent looping and unwanted broadcast traffic. Let’s go into the explanation. Using Native VLAN 1 in a network that employs VLANs can create potential looping and broadcast issues if not managed properly. The Native VLAN is an untagged VLAN used to carry untagged traffic. On many networking devices, VLAN 1 is set as the default Native VLAN.
Looping and broadcast issues can occur in the following situations:
- Native VLAN Mismatch: If there is a configuration mismatch between connected devices ex; one device has Native VLAN 1 while the other uses a different Native VLAN—the untagged traffic may be misinterpreted, potentially causing loops.
- Double Tagging (Q-in-Q): If a device sends a tagged packet (with a VLAN ID) to a port configured with Native VLAN 1 and adds VLAN 1 tagging again before sending it out, double tagging occurs. This can create network issues and loops on other devices.
- Unintentional Inclusion in Trunk Links: VLAN 1 can sometimes be accidentally included in trunk links (paths that carry multiple VLANs across the network). If Native VLAN 1 traffic enters a trunk and is misinterpreted by the receiving device, it can cause looping.
To avoid these problems, careful VLAN configuration is essential. Best practices to prevent looping caused by Native VLAN 1 include:
- Change the Native VLAN: Change the Native VLAN from the default value (1) to a VLAN ID that is not used by other VLANs, reducing the risk of loops.
- Separate Data and Management Traffic: Use different VLANs for user data and management traffic. Avoid using VLAN 1 for user data.
- Monitoring and Understanding: Monitor VLAN configurations on all network devices and understand how VLANs and Native VLANs operate to identify and fix potential issues before loops occur.
Therefore, to prevent looping and broadcast, the Native VLAN must be redefined and changed from the default VLAN 1. In this setup, I use Native VLAN 800, and on the opposite side, Native VLAN 975 is configured. Only the required VLANs are allowed. When properly configured, VLAN 1 traffic will no longer pass through, making this method effective in preventing network loops and broadcast. The MAC addresses carried by VLAN 1 need to be analyzed.
ex, before:
pop_nue6969#show mac address-table vlan 1
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 xxxx.314c.51cb DYNAMIC Gi0/1
1 xxxx.314c.51cc DYNAMIC Gi0/1
1 xxxx.31d2.edfb DYNAMIC Gi0/1
1 xxxx.5ab9.5c89 DYNAMIC Gi0/1
1 xxxx.5afa.6138 DYNAMIC Gi0/1
1 xxxx.f461.9be2 DYNAMIC Gi0/1
1 xxxx.f461.9be3 DYNAMIC Gi0/1
1 xxxx.xxxx.4c98 DYNAMIC Gi0/1
after party ^_^:
pop_nue6969#show mac address-table interface fastEthernet 0/4
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
800 xxxx.6938.3c40 DYNAMIC Fa0/4
800 xxxx.3216.6c37 DYNAMIC Fa0/4
800 xxxx.aeb4.8be7 DYNAMIC Fa0/4
95 xxxx.a11c.8c20 DYNAMIC Fa0/4
95 xxxx.f988.69eb DYNAMIC Fa0/4
95 xxxx. xxxx.abf7 DYNAMIC Fa0/4
Based on this case study of basic network issues with an ISP covering an apartment area, this is one of the recurring problems. Understand the concepts of handling both Layer 1 and Layer 2 network issues.
Hahaha alright, that’s a wrap for today’s article—my coffee’s gone, so that’s my cue to stop typing.
Let’s end this with a Bismillah at the start and an Alhamdulillah at the finish. Catch you next time, tech gembelers!.
./Nuenomaru
EmoticonEmoticon