El 21 de febrero de 2017 7:00:03 GMT-05:00, centos-request at centos.org escribi?:>Send CentOS mailing list submissions to > centos at centos.org > > >From: Kahlil Hodgson <kahlil.hodgson at dp.exchange> >To: CentOS mailing list <centos at centos.org> >Subject: Re: [CentOS] Network conections problems> >First guess is that you may have two devices on the network with the >same ip address. > >Next time this happens, try doing > >1. 'arp -n' from a machine other than the db server >2. ping the other machine from the db server, then >3. 'arp -n' from the other machine > >Compare the outputs of the two invocations of arp. If the outputs show >different MAC addresses for 192.168.41.4 then you have two different >devices with the same IP address. > >I resolve the problem of network conection loose, but still a dude of how it happend and how it can be fixe. When I check with arping the MAC of sever change, for example rommel at p6:~$ arping 192.168.41.4 ARPING 192.168.41.4 from 192.168.41.6 enp3s0 Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.653ms Unicast reply from 192.168.41.4 [6C:92:BF:26:C7:03] 0.683ms Unicast reply from 192.168.41.4 [6C:92:BF:26:C7:03] 0.622ms Unicast reply from 192.168.41.4 [6C:92:BF:26:C7:03] 0.631ms ^CSent 3 probes (1 broadcast(s)) Received 4 response(s) The first answer is with a MAC diferent to the others one. But when I arping from the server inseft look the MAC associate to de IP address: [root at pgtm ] arping 192.168.41.4 -I eth1 ARPING 192.168.41.4 from 192.168.41.4 eth1 Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.658ms Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.654ms Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.654ms Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.662ms Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.655ms Sent 5 probes (1 broadcast(s)) Received 5 response(s) Looking in the config of network device I can not find the MAC 00:1D:09:FF:44:4B [root at pgtm ] ifconfig eth0 Link encap:Ethernet HWaddr 6C:92:BF:26:C7:02 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Memory:c7220000-c723ffff eth1 Link encap:Ethernet HWaddr 6C:92:BF:26:C7:03 inet addr:192.168.41.4 Bcast:192.168.41.255 Mask:255.255.255.0 inet6 addr: fe80::6e92:bfff:fe26:c703/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:95819 errors:0 dropped:0 overruns:0 frame:0 TX packets:1924 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:11728605 (11.1 MiB) TX bytes:263674 (257.4 KiB) Memory:c7200000-c721ffff eth2 Link encap:Ethernet HWaddr 00:E0:ED:33:4E:9C UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Memory:c7120000-c713ffff eth3 Link encap:Ethernet HWaddr 00:E0:ED:33:4E:9D UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Memory:c7100000-c711ffff lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:249609 errors:0 dropped:0 overruns:0 frame:0 TX packets:249609 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:52090343 (49.6 MiB) TX bytes:52090343 (49.6 MiB) The solution was another IP address to this network device and then everything work fine. Why this happend? How I can erase the link beteewn MAC 00:1D:09:FF:44:4B and IP 192.168.41.4? Where can be stored this link? Right now in the network is not assignet the IP address 192.168.41.4 to no one device (printserver, switch, router, workstation or server) and still whe I make arping have the answer: rommel at p6:~$ arping 192.168.41.4 ARPING 192.168.41.4 from 192.168.41.6 enp3s0 Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.631ms Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.623ms Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.623ms Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.691ms ^CSent 4 probes (1 broadcast(s)) Received 4 response(s) arping to the new server IP address look like this (this is the MAC of eth0, where a plug the network cable): rommel at p6:~$ arping 192.168.41.7 ARPING 192.168.41.7 from 192.168.41.6 enp3s0 Unicast reply from 192.168.41.7 [6C:92:BF:26:C7:02] 0.580ms Unicast reply from 192.168.41.7 [6C:92:BF:26:C7:02] 0.607ms Unicast reply from 192.168.41.7 [6C:92:BF:26:C7:02] 0.613ms Unicast reply from 192.168.41.7 [6C:92:BF:26:C7:02] 0.594ms ^CSent 4 probes (1 broadcast(s)) Received 4 response(s) Rommel Rodriguez Toirac rommelrt at nauta.cu
Yup, my guess is that someone has plugged in another device into your network and that device has a ip address 192.168.41.4 statically assigned. Or someone has reconfigured a device and set that address by accident. I had a UPS do this to me once. A quick lookup on the https://macvendors.com/ shows the offending mac address belongs to a device from Dell Inc. That may help you track down the offender. Hope this helps. On Thu, Feb 23, 2017 at 8:27 AM, Rommel Rodriguez Toirac <rommelrt at nauta.cu> wrote:> El 21 de febrero de 2017 7:00:03 GMT-05:00, centos-request at centos.org escribi?: >>Send CentOS mailing list submissions to >> centos at centos.org >> >> >>From: Kahlil Hodgson <kahlil.hodgson at dp.exchange> >>To: CentOS mailing list <centos at centos.org> >>Subject: Re: [CentOS] Network conections problems > >> >>First guess is that you may have two devices on the network with the >>same ip address. >> >>Next time this happens, try doing >> >>1. 'arp -n' from a machine other than the db server >>2. ping the other machine from the db server, then >>3. 'arp -n' from the other machine >> >>Compare the outputs of the two invocations of arp. If the outputs show >>different MAC addresses for 192.168.41.4 then you have two different >>devices with the same IP address. >> >> > I resolve the problem of network conection loose, but still a dude of how it happend and how it can be fixe. > When I check with arping the MAC of sever change, for example > > rommel at p6:~$ arping 192.168.41.4 > ARPING 192.168.41.4 from 192.168.41.6 enp3s0 > Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.653ms > Unicast reply from 192.168.41.4 [6C:92:BF:26:C7:03] 0.683ms > Unicast reply from 192.168.41.4 [6C:92:BF:26:C7:03] 0.622ms > Unicast reply from 192.168.41.4 [6C:92:BF:26:C7:03] 0.631ms > ^CSent 3 probes (1 broadcast(s)) > Received 4 response(s) > > The first answer is with a MAC diferent to the others one. > But when I arping from the server inseft look the MAC associate to de IP address: > > [root at pgtm ] arping 192.168.41.4 -I eth1 > ARPING 192.168.41.4 from 192.168.41.4 eth1 > Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.658ms > Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.654ms > Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.654ms > Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.662ms > Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.655ms > Sent 5 probes (1 broadcast(s)) > Received 5 response(s) > > Looking in the config of network device I can not find the MAC 00:1D:09:FF:44:4B > > [root at pgtm ] ifconfig > eth0 Link encap:Ethernet HWaddr 6C:92:BF:26:C7:02 > UP BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) > Memory:c7220000-c723ffff > > eth1 Link encap:Ethernet HWaddr 6C:92:BF:26:C7:03 > inet addr:192.168.41.4 Bcast:192.168.41.255 Mask:255.255.255.0 > inet6 addr: fe80::6e92:bfff:fe26:c703/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:95819 errors:0 dropped:0 overruns:0 frame:0 > TX packets:1924 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:11728605 (11.1 MiB) TX bytes:263674 (257.4 KiB) > Memory:c7200000-c721ffff > > eth2 Link encap:Ethernet HWaddr 00:E0:ED:33:4E:9C > UP BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) > Memory:c7120000-c713ffff > > eth3 Link encap:Ethernet HWaddr 00:E0:ED:33:4E:9D > UP BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) > Memory:c7100000-c711ffff > > lo Link encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:65536 Metric:1 > RX packets:249609 errors:0 dropped:0 overruns:0 frame:0 > TX packets:249609 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:52090343 (49.6 MiB) TX bytes:52090343 (49.6 MiB) > > The solution was another IP address to this network device and then everything work fine. > Why this happend? How I can erase the link beteewn MAC 00:1D:09:FF:44:4B and IP 192.168.41.4? Where can be stored this link? > Right now in the network is not assignet the IP address 192.168.41.4 to no one device (printserver, switch, router, workstation or server) and still whe I make arping have the answer: > > rommel at p6:~$ arping 192.168.41.4 > ARPING 192.168.41.4 from 192.168.41.6 enp3s0 > Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.631ms > Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.623ms > Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.623ms > Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.691ms > ^CSent 4 probes (1 broadcast(s)) > Received 4 response(s) > > arping to the new server IP address look like this (this is the MAC of eth0, where a plug the network cable): > > rommel at p6:~$ arping 192.168.41.7 > ARPING 192.168.41.7 from 192.168.41.6 enp3s0 > Unicast reply from 192.168.41.7 [6C:92:BF:26:C7:02] 0.580ms > Unicast reply from 192.168.41.7 [6C:92:BF:26:C7:02] 0.607ms > Unicast reply from 192.168.41.7 [6C:92:BF:26:C7:02] 0.613ms > Unicast reply from 192.168.41.7 [6C:92:BF:26:C7:02] 0.594ms > ^CSent 4 probes (1 broadcast(s)) > Received 4 response(s) > > > > Rommel Rodriguez Toirac > rommelrt at nauta.cu > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos-- Kahlil (Kal) Hodgson GPG: C9A02289 Chief Technology Officer (m) +61 (0) 4 2573 0382 Direct Pricing Exchange Pty Ltd Suite 1415 401 Docklands Drive Docklands VIC 3008 Australia "All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer." -- IBM maintenance manual, 1925
On 23/02/17 08:27, Rommel Rodriguez Toirac wrote:> The solution was another IP address to this network device and then > everything work fine. > Why this happend? How I can erase the link beteewn MAC 00:1D:09:FF:44:4B and IP 192.168.41.4? Where can be stored this link? > Right now in the network is not assignet the IP address 192.168.41.4 to no one device (printserver, switch, router, workstation or server) and still whe I make arping have the answer: > > rommel at p6:~$ arping 192.168.41.4 > ARPING 192.168.41.4 from 192.168.41.6 enp3s0 > Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.631ms > Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.623ms > Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.623ms > Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.691ms > ^CSent 4 probes (1 broadcast(s)) > Received 4 response(s)One thing to try if you have access to the switch where all the devices are plugged in: *$ sudo ping -f 192.168.41.4* Then watch the switch for a lot of activity on 2 ports - the one you are plugged into and another. The other busy port will be the one that's causing you grief. If you have daisy chained switches, then it might take a little longer to track it down. Happy hunting - :).
On 23/02/17 17:54, Anthony K wrote:> On 23/02/17 08:27, Rommel Rodriguez Toirac wrote: >> The solution was another IP address to this network device and then >> everything work fine. >> Why this happend? How I can erase the link beteewn MAC >> 00:1D:09:FF:44:4B and IP 192.168.41.4? Where can be stored this link? >> Right now in the network is not assignet the IP address >> 192.168.41.4 to no one device (printserver, switch, router, >> workstation or server) and still whe I make arping have the answer: >> >> rommel at p6:~$ arping 192.168.41.4 >> ARPING 192.168.41.4 from 192.168.41.6 enp3s0 >> Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.631ms >> Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.623ms >> Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.623ms >> Unicast reply from 192.168.41.4 [00:1D:09:FF:44:4B] 0.691ms >> ^CSent 4 probes (1 broadcast(s)) >> Received 4 response(s) > > One thing to try if you have access to the switch where all the > devices are plugged in: > *$ sudo ping -f 192.168.41.4* > > Then watch the switch for a lot of activity on 2 ports - the one you > are plugged into and another. The other busy port will be the one > that's causing you grief. If you have daisy chained switches, then it > might take a little longer to track it down. > > Happy hunting - :). > _______________________________________________Another solution, if you are the admin with access to the router, is to null route the packets from that IP. The person using that device will let you know shortly after (lack of Internet access is the quickest way to get the attention of users on the network): $ sudo ip r a blackhole 192.168.41.4