New answers tagged arp
It appears that dot1x vs SNMP is what makes a difference there. dot1x communicates the addition/disconnect of bridged devices. Now why that is I have no clue - but at least that is a solution of sorts
Focus on the changes you made that could have impacted this. You made changes to the Aironets, and now 1/2 your wireless PCs are impacted. You should be smart and simply revert those changes immediately, to restore service to your users. Then, you could test those changes one-by-one, preferably in a test environment, to see which of those changes (or ...
It's not clear to me what the "intention" of your question is, but let me make a few points: A switch floods ethernet frames to all switch ports when it doesn't have a MAC address to switch port mapping for the destination MAC address. ARP resolves IP addresses to MAC addresses. A switch doesn't perform ARP unlesss the switch itself is communicating with a ...
Possible ways: Download and install NMAP and run. nmap -sP 192.168.0.0/24. Assuming you IP range is 192.168.0.0. Ping the networks broadcast address, which will get every host to reply, but only if they have a working IP. Then check your ARP tables. If you can get access to the switch. Check MAC address and or forwarding table. If you know the port the ...
If you have no access to switches to get ARP tables, your last resort can be physical access to the cameras: all cams I've seen had a sticker or other label with serial number and MAC-address, unless someone removed these labels. Also, if these cameras sending their signal somewhere, there must be a kind of list with their IPs and so on. Another way: ...
Have the network team get you a copy of the arp tables from the switches with a filter by the subnet that the cameras are on. Cisco command to show IP to mac address use: show arp | include "regular-expression" Cisco command to show Mac address without an IP: show mac-address-table (you could filter on mac addresses OUI that you know could be at the site) ...
This is not possible via SNMP as long as those subtrees are not supported. Regardless of the MIB you use, the values won't be populated from the ACE.
In order to get the switch(es) routing table to update, the server needs to send out via its new IP, so that the new MAC can be known. To do this I simply restarted the server - It seems on boot the NIC must send out some sort of data from all of its configured IP addresses.
ipconfig /flushdns on the client should do the trick. If it's the router that's the issue, flushing the ARP cache would work. Correction, I realized this was when changing DNS records, not moving IPs. Please disregard.
60 seconds you can check it with: cat /proc/sys/net/ipv4/neigh/ethX/gc_stale_time and change it with echo timeout > /proc/sys/net/ipv4/neigh/ethX/gc_stale_time timeout is new value
OK. Everything is correct. If there is no default gateway configured on the interface and there is proxy-arp configured on switch port, then if you ping ip address outside network configured on the iface, you will get arp entry in your arp table with ip address outside current network. Thats the normal behaviour :]. I've checked this manually on lab switch.
netsh interface ipv4 add neighbors "Local Area Connection" 10.1.1.1 12-34-56-78-9a-bc this will create a static arp entry that survives reboots. be careful adding the routes though, as you may not be able to remove them without a hotfix: https://support.microsoft.com/en-us/kb/2718830
It sounds like the Cisco interface your eth0 is connected to is configured with ip local-proxy-arp but the Cisco interface your eth1 connects to is actually configured with ip proxy-arp instead. This would account for the switch taking responsibility over the data-link addressing of an IP outside of the locally configured LAN. Can you please verify this on ...
Top 50 recent answers are included