Normally the table is built dynamically, but to increase network security, it can be partially or completely built statically by means of adding static entries. Router has a table of currently used ARP entries.
#MIKROTIK ADDRESS LIST ARP MAC#
Address Resolution Protocol is used to map OSI level 3 IP addresses to OSI level 2 MAC addreses. Problems I have seen when this happen are L2 loops or situations where one device is sending traffic to the second while the second device has the port in a STP blocking state.Even though IP packets are addressed using IP addresses, hardware addresses must be used to actually transport data from one host to another. My guess is that you had a problem with STP, which can happen when you don't configure your link aggregations properly on both sides. Did you change anything on swt-d-1? If so, what? In your fix, you only mention changing the Cloud Core from balance-rr to 802.3ad. What kind of mechanism at CC1036 has been activated that cause gaps in the ARP tables across the entire network many devices further ?! Part of being a good network troubleshooter is being able to separate the actual problem from the symptoms. Second, misconfiguring a network device can create all sorts of unintended problems. Why configuration at layer 2 at layer 3 device at different site of LAN caused problem at another part of the network ?!įirst, to be clear, since you mentioned that you are bridging the interfaces on the Cloud Core, this is part of the same L2 LAN, not a "different site." When I reconfigured CC1036 and changed bonding protocol from balanced-rr to the 802.3ad between CC1036 and swt-d-1 the entire network began working well !!! All hosts began see each other, connectivity problems with Nas server disappeared, and all ARP tables have become complete. Theoretically frames and packets shouldn't leave swt-d-3 switch because problematic traffic was limited to hosts connected to this switch ports. It was strange because problem was isolated to the Local station 3 LAN part. When I disconnected at swt-d-3 switch link E23 to the CC1036 trying to replace that switch - monitoring server showed that problem disappear immediately. I suspected that there is problem with swt-d-3. The same was when I tried to connecto to different hosts at Local station 3 LAN site.Īlso ARP tables at hosts at Local station 3 wasn't complete !!! They didn't know about MAC addresses of their closest neighbors !!! Bonding-1 - I bounded 3 links between CC1036 and swt-d-1 switch at swt-d-1 I used trunks at E22, E23, E24 interfaces and at CC1036 at E1, E2, E3 I used balanced-rr protocol and I add that Bond to the bridge.Īt first look everything was fine - all hosts had access to the Internet and between them along the LAN.įirst symptom was loosing connectivity to the NAS server from whole LAN site and from Internet using VPN.Īlso some host from Local station 3 site couldn't localized LAN printers at Local station 1 - there was PING problems, etc.Local station x - hosts connected to the network using DHCP server defined at CC1036 MikrotikRouter,.swt-a-x switches - my acces layer switches all HP 1810-8G - J9802A with one default VLAN,.swt-d-x switches - my distribution layer switches all HP 1810-24G - J9803A with one default VLAN,.CloudCore 1036 - main router with one bridge and included one link bond (causing issue balanced-rr and not causing issue 802.3ad,.All CC1036 interfaces were arp-proxy and arp-enabled mode. Main router based on Mikrotik CloudCore1036 within one bridge and HP switches 1810-24G and 1810-8G - all default configured within default VLAN. In the ARP tables across the entire network many devices further ?!Īt above picture You can see part of my network scheme. What kind of mechanism at CC1036 has been activated that cause gaps.LAN caused problem at another part of the network ?! Why configuration at layer 2 at layer 3 device at different site of.
0 kommentar(er)
