LINUX.ORG.RU
Форум — General  

Xubuntu почему-то маршрутизирует в себя.

 , , ,


1

3

Всем привет. Сразу скажу что я не нуб и не особо люблю пользоваться форумами для помощи но тут особый случай.

Суть в том что на машине с xubuntu виден интернет и несколько сетей за роутером. Но компьютеры находящиеся в одной сети с машиной не видны. Из винды глюка не наблюдается.

Вот пример. На компе ip адрес 192.168.1.2 маска 24, прописан статически, шлюз 192.168.1.100, dns 192.168.1.100 В сети есть 192.168.1.5, это файлопомойка. 100% она онлайн. И

ip addr show enp23s0f0 

2: enp23s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 90:e2:ba:48:c7:28 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.2/24 brd 192.168.1.255 scope global noprefixroute enp23s0f0
       valid_lft forever preferred_lft forever
    inet6 fe80::f6ee:e7ac:1bbb:8cf4/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

netstat -rn 

Таблица маршутизации ядра протокола IP
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0         192.168.1.100   0.0.0.0         UG        0 0          0 enp23s0f0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 enp23s0f0
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 enp23s0f0

ip route show

default via 192.168.1.100 dev enp23s0f0 proto static metric 100 
169.254.0.0/16 dev enp23s0f0 scope link metric 1000 
192.168.1.0/24 dev enp23s0f0 proto kernel scope link src 192.168.1.2 metric 100

ip rule list

0:      from all lookup local 
32766:  from all lookup main 
32767:  from all lookup default

iptables -L

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

iptables -L -t nat

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

ping 192.168.1.100 

PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
64 bytes from 192.168.1.100: icmp_seq=1 ttl=64 time=0.234 ms
64 bytes from 192.168.1.100: icmp_seq=2 ttl=64 time=0.147 ms
64 bytes from 192.168.1.100: icmp_seq=3 ttl=64 time=0.219 ms
^C
--- 192.168.1.100 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 50ms
rtt min/avg/max/mdev = 0.147/0.200/0.234/0.037 ms

ping 192.168.5.3 

ING 192.168.5.3 (192.168.5.3) 56(84) bytes of data.
64 bytes from 192.168.5.3: icmp_seq=1 ttl=63 time=5.67 ms
64 bytes from 192.168.5.3: icmp_seq=2 ttl=63 time=13.1 ms
64 bytes from 192.168.5.3: icmp_seq=3 ttl=63 time=3.85 ms
^C
--- 192.168.5.3 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 3.851/7.523/13.051/3.978 ms

ping 8.8.8.8 

ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=47 time=47.1 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=47 time=46.8 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=47 time=46.9 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 46.829/46.950/47.089/0.106 ms

ping 192.168.1.5 

PING 192.168.1.5 (192.168.1.5) 56(84) bytes of data.
From 192.168.1.2 icmp_seq=1 Destination Host Unreachable
From 192.168.1.2 icmp_seq=2 Destination Host Unreachable
From 192.168.1.2 icmp_seq=3 Destination Host Unreachable
^C
--- 192.168.1.5 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 73ms
pipe 4

traceroute 8.8.8.8 

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  _gateway (192.168.1.100)  0.324 ms  0.305 ms  0.291 ms
 2  178.34.128.35 (178.34.128.35)  8.091 ms  7.536 ms  7.681 ms
 3  178.34.129.130 (178.34.129.130)  6.950 ms  6.950 ms  6.928 ms
 4  87.226.183.89 (87.226.183.89)  30.658 ms  30.108 ms  30.253 ms
 5  5.143.253.245 (5.143.253.245)  29.788 ms 74.125.51.172 (74.125.51.172)  29.955 ms 5.143.253.105 (5.143.253.105)  29.931 ms
 6  108.170.250.66 (108.170.250.66)  28.962 ms 108.170.250.34 (108.170.250.34)  28.693 ms 108.170.250.113 (108.170.250.113)  28.836 ms
 7  216.239.50.132 (216.239.50.132)  44.314 ms 209.85.249.158 (209.85.249.158)  45.204 ms 216.239.51.32 (216.239.51.32)  45.595 ms
 8  74.125.253.109 (74.125.253.109)  47.329 ms 72.14.238.168 (72.14.238.168)  43.235 ms 172.253.66.108 (172.253.66.108)  43.516 ms
 9  172.253.51.247 (172.253.51.247)  47.075 ms  44.948 ms 216.239.47.165 (216.239.47.165)  44.889 ms^C

traceroute 192.168.1.5 

traceroute to 192.168.1.5 (192.168.1.5), 30 hops max, 60 byte packets
 1  asus-x299-a-i7-7800x (192.168.1.2)  3051.142 ms !H  3051.107 ms !H  3051.092 ms !H

при попытке пингануть себя с 192.168.1.5 ответа нет. захватил трафик через tcpdump -i enp23s0f0 -nn icmp 

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp23s0f0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:07:56.185079 IP 192.168.1.5 > 192.168.1.2: ICMP echo request, id 7711, seq 41, length 64
00:07:57.257715 IP 192.168.1.5 > 192.168.1.2: ICMP echo request, id 7711, seq 42, length 64
00:07:58.330341 IP 192.168.1.5 > 192.168.1.2: ICMP echo request, id 7711, seq 43, length 64
00:07:59.390011 IP 192.168.1.5 > 192.168.1.2: ICMP echo request, id 7711, seq 44, length 64
00:08:00.462675 IP 192.168.1.5 > 192.168.1.2: ICMP echo request, id 7711, seq 45, length 64
00:08:01.516460 IP 192.168.1.5 > 192.168.1.2: ICMP echo request, id 7711, seq 46, length 64
^C
6 packets captured
6 packets received by filter
0 packets dropped by kernel

Подскажите что может быть и как можно исправить. Появилось всё после того как я пытался создать bond в network-manager. Естественно все бонды я удалил и модули отключил. Кроме физических интерфейсов, ни каких других не настроено. Пробовал вставлять кабель в доугой интерфейс, эффекта не даёт.

← Проблема с libgcc_s.so.1
Debian 10.1, XEN 4.11 и 4 сети →

Посмотрите содержимое таблицы маршрутизации ″local″ и проверьте с помощью arping, что 192.168.1.5 отвечает на arp-запросы. Ну и arp-таблицу посмотрите. C ebtables и пр. не игрались?

mky ★★★★★
()
Ответ на: комментарий от mky

arp -a 

? (169.254.228.173) в 60:a4:4c:4d:51:83 [ether] на enp23s0f0
? (192.168.1.101) в 60:a4:4c:4d:51:83 [ether] на enp23s0f0
? (192.168.1.5) в fe:a1:b9:5a:56:a4 [ether] на enp23s0f0
_gateway (192.168.1.100) в 74:4d:28:64:6b:b4 [ether] на enp23s0f0

sudo arping -I enp23s0f0 192.168.1.5 

ARPING 192.168.1.5 from 192.168.1.2 enp23s0f0


^CSent 73 probes (73 broadcast(s))
Received 0 response(s)
arping просто стоит и ничего не делает. если сделать arping на роутер то пингуется.

ip route show table local 

broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 
broadcast 192.168.1.0 dev enp23s0f0 proto kernel scope link src 192.168.1.2 
local 192.168.1.2 dev enp23s0f0 proto kernel scope host src 192.168.1.2 
broadcast 192.168.1.255 dev enp23s0f0 proto kernel scope link src 192.168.1.2

ebtables не ставил на эту машину никогда.

vanohaker
() автор топика
Ответ на: комментарий от vanohaker

arping просто стоит и ничего не делает

Вобще, в этот момент tcpdump должен показывать arp-запросы (и ответы, если всё нормально).

arp -a

ip neigh show

fe:a1:b9:5a:56:a4 странный mac-адрес, его нет в базе производителей сетевого оборудования...

mky ★★★★★
()
Ответ на: комментарий от mky

Вобще, в этот момент tcpdump должен показывать arp-запросы (и ответы, если всё нормально).

sudo tcpdump -i enp23s0f0 -nn arp во время sudo arping -I enp23s0f0 192.168.1.5 

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp23s0f0, link-type EN10MB (Ethernet), capture size 262144 bytes
01:23:28.325950 ARP, Request who-has 192.168.1.5 (ff:ff:ff:ff:ff:ff) tell 192.168.1.2, length 28
01:23:28.326628 ARP, Reply 192.168.1.5 is-at fe:a1:b9:5a:56:a4, length 46
01:23:29.326045 ARP, Request who-has 192.168.1.5 (ff:ff:ff:ff:ff:ff) tell 192.168.1.2, length 28
01:23:29.326741 ARP, Reply 192.168.1.5 is-at fe:a1:b9:5a:56:a4, length 46
01:23:30.326140 ARP, Request who-has 192.168.1.5 (ff:ff:ff:ff:ff:ff) tell 192.168.1.2, length 28
01:23:30.326668 ARP, Reply 192.168.1.5 is-at fe:a1:b9:5a:56:a4, length 46
01:23:31.326230 ARP, Request who-has 192.168.1.5 (ff:ff:ff:ff:ff:ff) tell 192.168.1.2, length 28
01:23:31.326762 ARP, Reply 192.168.1.5 is-at fe:a1:b9:5a:56:a4, length 46
01:23:32.326328 ARP, Request who-has 192.168.1.5 (ff:ff:ff:ff:ff:ff) tell 192.168.1.2, length 28
01:23:32.326834 ARP, Reply 192.168.1.5 is-at fe:a1:b9:5a:56:a4, length 46
01:23:33.326423 ARP, Request who-has 192.168.1.5 (ff:ff:ff:ff:ff:ff) tell 192.168.1.2, length 28
01:23:33.326967 ARP, Reply 192.168.1.5 is-at fe:a1:b9:5a:56:a4, length 46
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel

ip netgh show 

169.254.228.173 dev enp23s0f0 lladdr 60:a4:4c:4d:51:83 STALE
192.168.1.101 dev enp23s0f0 lladdr 60:a4:4c:4d:51:83 STALE
192.168.1.5 dev enp23s0f0 lladdr fe:a1:b9:5a:56:a4 STALE
192.168.1.100 dev enp23s0f0 lladdr 74:4d:28:64:6b:b4 REACHABLE

fe:a1:b9:5a:56:a4 странный mac-адрес, его нет в базе производителей сетевого оборудования...

помойка стоит на proxmox до которой дотянуты через vlan сетки ip телефонии и умного дома которые работают без проблем. скорее всего mac такой потому что сгенерирован виртуалкой. с других компов, медиацентров и винды всё нормально работает.

vanohaker
() автор топика

помойка стоит на proxmox

Может на 192.168.1.5 статически прописан мак для 192.168.1.2 или не может увидеть/обновить?
Глянь ip ne show и tcpdump на обоих хостах.
С хоста 192.168.1.5 пингани 192.168.1.2

DiMoN ★★★
()
Последнее исправление: DiMoN (всего исправлений: 1)
Ответ на: комментарий от DiMoN

Может на 192.168.1.5 статически прописан мак для 192.168.1.2 или не может увидеть/обновить?

Если перезагрузить проблемную машину в винду то помойка открывается нормально и все машины в сети видятся. При этом кабель вставлен в тоже сетевую карту. Не думаю что дело в роутере, свичах или самой помойке. Мне кажется что проблема софтовая. Гдето как будто прописан маршрут на подобие 

0.0.0.0        192.168.1.100  0.0.0.0
192.168.1.0    0.0.0.0        255.255.255.0
192.168.1.0    192.168.1.2    255.255.255.0

Или как то так, но при этом все таблицы по моему в порядке.

Вот arp таблица с роутера и dhcp с адресами кому и что раздал dhcp сервер.

https://ibb.co/m0qXVh8

https://ibb.co/kJ6PMRK

Делаю пинг с проблемной машины на файлопомойку 192.168.1.5 

vanohaker@asus-x299-a-i7-7800x:~$ ping 192.168.1.5
PING 192.168.1.5 (192.168.1.5) 56(84) bytes of data.
From 192.168.1.2 icmp_seq=1 Destination Host Unreachable
From 192.168.1.2 icmp_seq=2 Destination Host Unreachable
From 192.168.1.2 icmp_seq=3 Destination Host Unreachable
From 192.168.1.2 icmp_seq=4 Destination Host Unreachable
From 192.168.1.2 icmp_seq=5 Destination Host Unreachable
From 192.168.1.2 icmp_seq=6 Destination Host Unreachable
^C
--- 192.168.1.5 ping statistics ---
7 packets transmitted, 0 received, +6 errors, 100% packet loss, time 155ms
pipe 4

ситуация на помойке в это время 

root@server1:~ # tcpdump -i vtnet0 -nn icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vtnet0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
59 packets received by filter
0 packets dropped by kernel

обратный пинг с помойки на проблемную машину 

root@server1:~ # ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2): 56 data bytes
^C
--- 192.168.1.2 ping statistics ---
8 packets transmitted, 0 packets received, 100.0% packet loss

ситуация на проблемной машине 

vanohaker@asus-x299-a-i7-7800x:~$ sudo tcpdump -i enp23s0f0 -nn icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp23s0f0, link-type EN10MB (Ethernet), capture size 262144 bytes
12:19:44.725564 IP 192.168.1.5 > 192.168.1.2: ICMP echo request, id 18997, seq 0, length 64
12:19:45.793211 IP 192.168.1.5 > 192.168.1.2: ICMP echo request, id 18997, seq 1, length 64
12:19:46.804979 IP 192.168.1.5 > 192.168.1.2: ICMP echo request, id 18997, seq 2, length 64
12:19:47.877536 IP 192.168.1.5 > 192.168.1.2: ICMP echo request, id 18997, seq 3, length 64
12:19:48.924852 IP 192.168.1.5 > 192.168.1.2: ICMP echo request, id 18997, seq 4, length 64
^C
5 packets captured
5 packets received by filter
0 packets dropped by kernel
то есть icmp прилетает но ответа машина послать не может.

пинг osmc медиацентра с проблемной машины 

vanohaker@asus-x299-a-i7-7800x:~$ ping 192.168.1.103
PING 192.168.1.103 (192.168.1.103) 56(84) bytes of data.
From 192.168.1.2 icmp_seq=1 Destination Host Unreachable
From 192.168.1.2 icmp_seq=2 Destination Host Unreachable
From 192.168.1.2 icmp_seq=3 Destination Host Unreachable
From 192.168.1.2 icmp_seq=4 Destination Host Unreachable
From 192.168.1.2 icmp_seq=5 Destination Host Unreachable
From 192.168.1.2 icmp_seq=6 Destination Host Unreachable
^C
--- 192.168.1.103 ping statistics ---
7 packets transmitted, 0 received, +6 errors, 100% packet loss, time 150ms
pipe 4

но при этом идёт пинг роутера 

vanohaker@asus-x299-a-i7-7800x:~$ ping 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
64 bytes from 192.168.1.100: icmp_seq=1 ttl=64 time=0.232 ms
64 bytes from 192.168.1.100: icmp_seq=2 ttl=64 time=0.159 ms
64 bytes from 192.168.1.100: icmp_seq=3 ttl=64 time=0.228 ms
64 bytes from 192.168.1.100: icmp_seq=4 ttl=64 time=0.193 ms
64 bytes from 192.168.1.100: icmp_seq=5 ttl=64 time=0.232 ms
^C
--- 192.168.1.100 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 106ms
rtt min/avg/max/mdev = 0.159/0.208/0.232/0.034 ms

Глянь ip ne show и tcpdump на обоих хостах.

помойка на freebsd, по моему там не катит ip ne show

на проблемной xubuntu 

vanohaker@asus-x299-a-i7-7800x:~$ ip ne show
169.254.228.173 dev enp23s0f0  FAILED
192.168.1.103 dev enp23s0f0  FAILED
192.168.1.101 dev enp23s0f0 lladdr 60:a4:4c:4d:51:83 STALE
192.168.1.5 dev enp23s0f0  FAILED
192.168.1.13 dev enp23s0f0  FAILED
192.168.1.100 dev enp23s0f0 lladdr 74:4d:28:64:6b:b4 REACHABLE

vanohaker
() автор топика
Ответ на: комментарий от vanohaker

то есть icmp прилетает но ответа машина послать не может.

А она знает куда ответ посылать? На ней есть роут к необходимой сети?

Tesler
()
Ответ на: комментарий от vanohaker

mky правильно подметил странный адрес

fe:a1:b9:5a:56:a4 - такой адрес нельзя использовать для адресации хостов. 2 младших бита первого байта адреса должны быть 0.

Нужно идти на этот 192.168.1.5 и смотреть его настройки.

vel ★★★★★
()
Ответ на: комментарий от Tesler

А она знает куда ответ посылать? На ней есть роут к необходимой сети?

anohaker@asus-x299-a-i7-7800x:~$ ip route show
default via 192.168.1.100 dev enp23s0f0 proto static metric 100 
169.254.0.0/16 dev enp23s0f0 scope link metric 1000 
192.168.1.0/24 dev enp23s0f0 proto kernel scope link src 192.168.1.2 metric 100

судя по последней строчке маршрут в 192.168.1.0/24 есть

vanohaker
() автор топика
Ответ на: комментарий от Tesler

куда с ютуба пропал?

Ремонтирую квартиру. Я же живу не один, а с братом и его женой на одной квартире, и у них родилась дочь. В общем из-за выше сказанного с ютубом пришлось подвязать :) Как только закончу ремонт на квартире то обязательно вернусь к каналу. Тем более что с тех порт скил немного вырос.

vanohaker
() автор топика

если у Вас есть 169.254.х.х, вероятно либо физика не работает, либо что-то с другой стороны не работает(dhcp?).
это вроде last-resort, когда ничего не работает(dhcp/физика).
если ручками прописываете 192.168.1.x, после неудавшегося автомата - то мимо.

etwrq ★★★★★
()
Ответ на: комментарий от vel

fe:a1:b9:5a:56:a4 - такой адрес нельзя использовать для адресации хостов. 2 младших бита первого байта адреса должны быть 0.

Поменл mac на 00:A1:B9:5A:56:A4 Роутер сразу увидел что mac сменился в своей arp таблице 

[admin@MikroTik] /ip arp> pr
Flags: X - disabled, I - invalid, H - DHCP, D - dynamic, P - published, C - complete 
 #    ADDRESS         MAC-ADDRESS       INTERFACE                                                                                                          
 0 DC 192.168.1.111   D6:20:F6:44:3C:5A main_net                                                                                                           
 1 DC 192.168.1.103   B8:27:EB:D0:9B:CE main_net                                                                                                           
 2 DC 192.168.1.2     90:E2:BA:48:C7:28 main_net                                                                                                           
 3 DC 192.168.5.9     00:13:32:08:F8:3C managment                                                                                                          
 4 DC 192.168.1.106   38:A4:ED:BA:0C:1D main_net                                                                                                           
 5 DC 192.168.7.2     F6:36:DD:56:42:13 telephone                                                                                                          
 6 DC 192.168.1.5     00:A1:B9:5A:56:A4 main_net

А что плохого в том что младшие биты не 00? У меня 00 только на одной машине в сети а у всех остальных нет, и всё нормально работает и ни кто не жалуется.

vanohaker
() автор топика
Ответ на: комментарий от vanohaker

ах да. совсем забыл что после смены maс ситуация ни как не поменялась. все устройства в сети нормально работают друг с другом, только мой комп с адресом 192.168.1.2 не видит ни кого в сети 192.168.1.0/24 кроме роутера 192.168.1.100. все остальные сети видятся нормально.

vanohaker
() автор топика
Ответ на: комментарий от Tesler

вам с винфака вещают: https://support.microsoft.com/ru-ru/help/220874/how-to-use-automatic-tcp-ip-a...
зы. длинки/3комы так сетапятся - 169.254.(два последних байта с мака основого).
з.з.ы.
варианты:
статика - всё прописано в конфигах.
dhcp - работает, получаем конфигурацию, не работает - получаем 169.254.х.х.
не работает физика, но dhcp - получаем 169.254.х.х.
не работает физика и статика - получаем интерфейс в состоянии down.

etwrq ★★★★★
()
Последнее исправление: etwrq (всего исправлений: 2)
Ответ на: комментарий от etwrq

если проблемы с физикой, почему на другой ОС у него работает?

Tesler
()
Ответ на: комментарий от Tesler 
vanohaker@asus-x299-a-i7-7800x:~$ sudo ip route del 169.254.0.0/16 dev enp23s0f0 scope link metric 1000
vanohaker@asus-x299-a-i7-7800x:~$ sudo ip route del 192.168.1.0/24 dev enp23s0f0 proto kernel scope link src 192.168.1.2 metric 100
vanohaker@asus-x299-a-i7-7800x:~$ sudo ip route del default via 192.168.1.100 dev enp23s0f0 proto static metric 100
vanohaker@asus-x299-a-i7-7800x:~$ sudo ip route add 192.168.1.0/24 dev enp23s0f0 proto kernel scope link src 192.168.1.2
vanohaker@asus-x299-a-i7-7800x:~$ sudo ip route add default via 192.168.1.100 dev enp23s0f0
vanohaker@asus-x299-a-i7-7800x:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=47 time=47.0 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=47 time=46.9 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 46.878/46.954/47.031/0.229 ms
vanohaker@asus-x299-a-i7-7800x:~$ ping 192.168.1.5
PING 192.168.1.5 (192.168.1.5) 56(84) bytes of data.
^C
--- 192.168.1.5 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 30m

снёс все маршруты и добавил руками. эффекта нет.

vanohaker
() автор топика
Ответ на: комментарий от vanohaker

тут может быть что порт куда 1.5 подключен - switch-port protected(в терминах сисько, и эквивалентен по смыслу на другом оборудовании). вы этом случае он вам прямо на l2(arp в том числе), в одном vlan, не ответит :-)

etwrq ★★★★★
()
Последнее исправление: etwrq (всего исправлений: 3)
Ответ на: комментарий от vanohaker

такие адреса обычно не ходят через коммутаторы и мосты.

в твоем случае нужно начинать с arping и убедиться, что с L2 нет проблем.

Управляемые коммутаторы есть? Смотри на нем маки. Или в другой порт включи эту хубунту

На неуправляемых коммутаторах бывают такие проблемы. Помогает вкл/выкл.

vel ★★★★★
()
Ответ на: комментарий от vel

в твоем случае нужно начинать с arping и убедиться, что с L2 нет проблем.

с l2 со стороны коммутаторов проблем нет, отсутствие проблемы в другой os тому подтверждение.

вот в этом сообщении я делал arping c 192.168.1.2 на 192.168.1.5

Xubuntu почему-то маршрутизирует в себя. (комментарий)

Управляемые коммутаторы есть? Смотри на нем маки. Или в другой порт включи эту хубунту
На неуправляемых коммутаторах бывают такие проблемы. Помогает вкл/выкл.

все свичи управляемые. перезагружать пробовал первым делом. до роутера и от 192.168.1.2 и от 192.168.1.5 маки доходят. в arp роутера это видно https://ibb.co/m0qXVh8

vanohaker
() автор топика

В общем я устал спасать эту ось. Сейчас запишу на флешку ubuntu 19.10 и поставлю всё за ново. Конечно я согласен с тем что linux не убиваемая система и даже в этом случае она не умерла, а всего лишь заглючила но найти причину гоюка по моему не реально. В общем RIP и Reinstall. Всем спасибо за внимание.

vanohaker
() автор топика
Ответ на: комментарий от Tesler

Link-local addresses are assigned to interfaces by host-internal, i.e. stateless, address autoconfiguration when other means of address assignment are not available.
т.е. нету статики и не работает dhcp, либо нету физики и dhcp-клиент конфигурит интерфейс. когда нету физики и конфигурация интерфейса статика - интерфейс даже не подымается. ОП не указал как его сеть конфигурится, да и маки странные.

etwrq ★★★★★
()
Ответ на: комментарий от etwrq

Я кажется понимаю почему я дич начал говорить. Смотри. У меня есть простенький сервер, который собирает snooping database с дхцп релеев. Вот я его когда конфижил, сначала воткнул кабель ,а после начал конфижить адресацию, локально. Стыки у меня поднялись, все заработало, но в таблице маршрутизации все равно висел линк локал. И он там висел пока я ifup / ifdown на интерфейсе не сделал. Видимо по этому, с чего то и решил что он там всегда болтается. Опыта не много, как то значение не предал. Но тем не менее, у меня и сеть работала и адрес этот был. Хоть он там был и ненужен.

Tesler
()
Ответ на: комментарий от etwrq

Сейчас глянул, адрес линк локал только ипв6 висит. Но он то больше функций выполняет же, в отличии от линк локала ипв4.

Tesler
()
Ответ на: комментарий от vel

Я толком это не понял, самый младший бит это:

locally administered address bit

вроде он может быть не нулевым, адрес назначили вручную, а не выделили при производстве.

А следующий бит это:

group address bit

когда он ″1″, значит мультикаст.

Раз ″11″ пакеты не ходят, значит для мультикаста адреса должен выдавать производитель оборудования? :)

А ″FE″ используется linux bridge (или не только linux) и где-то должно быть написано про его особый смысл, но пока я не нашёл.

mky ★★★★★
()
Последнее исправление: mky (всего исправлений: 1)
Ответ на: комментарий от mky

эти два бита _в основном_ используются для работы в пределах линка.

Выпускать их за пределы линка можно, но только после осознания необходимости.

Раз ″11″ пакеты не ходят, значит для мультикаста адреса должен выдавать производитель оборудования? :)

Уже выданы :)

Для МС ipv4 есть отдельный диапазон МАС-ов 01:00:5E:00:00:00 - 01:00:5E:7F:FF:FF, а для MC ipv6 33:33:XX:XX:XX:XX

Там есть еще кучка адресов на 01 зарезервированных для всяких хитрых протоколов.

vel ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Проблема с libgcc_s.so.1
General
Debian 10.1, XEN 4.11 и 4 сети →