Страница 1 из 1

MES5324, странное поведение линка

Добавлено: 16 окт 2019 16:31
z117
Имеется интерфейс:

Код: Выделить всё

interface tengigabitethernet3/0/24
 ip address 192.168.173.249 255.255.255.0
 


Этот интерфейс соединён напрямую с 192.168.173.250.

Есть маршрут:

Код: Выделить всё

S   10.0.21.0/24 [1/4] via 192.168.173.250, 01:05:22, te3/0/24


Через несколько минут отсутствия активности на интерфейсе связь с 10.0.20.0/24 пропадает:

Код: Выделить всё

console#ping 10.0.21.10
Pinging 10.0.21.10 with 18 bytes of data:

PING: no reply from 10.0.21.10
PING: timeout
PING: no reply from 10.0.21.10
PING: timeout
PING: no reply from 10.0.21.10
PING: timeout
PING: no reply from 10.0.21.10
PING: timeout

----10.0.21.10 PING Statistics----
4 packets transmitted, 0 packets received, 100% packet loss


Но если пропинговать 192.168.173.250, то немедленно восстанавливается:

Код: Выделить всё

console#ping 192.168.173.250
Pinging 192.168.173.250 with 18 bytes of data:

18 bytes from 192.168.173.250: icmp_seq=1. time=0 ms
18 bytes from 192.168.173.250: icmp_seq=2. time=0 ms
18 bytes from 192.168.173.250: icmp_seq=3. time=0 ms
18 bytes from 192.168.173.250: icmp_seq=4. time=0 ms

----192.168.173.250 PING Statistics----
4 packets transmitted, 4 packets received, 0% packet loss
round-trip (ms) min/avg/max = 0/0/0

console#ping 10.0.21.10
Pinging 10.0.21.10 with 18 bytes of data:

18 bytes from 10.0.21.10: icmp_seq=1. time=0 ms
18 bytes from 10.0.21.10: icmp_seq=2. time=0 ms
18 bytes from 10.0.21.10: icmp_seq=3. time=0 ms
18 bytes from 10.0.21.10: icmp_seq=4. time=0 ms

----10.0.21.10 PING Statistics----
4 packets transmitted, 4 packets received, 0% packet loss
round-trip (ms) min/avg/max = 0/0/0


Почему такое может возникать и что делать?

Re: MES5324, странное поведение линка

Добавлено: 17 окт 2019 08:05
Александр Селезнев
Попробуйте настройки

Код: Выделить всё

interface tengigabitethernet3/0/24
 ip address 192.168.173.249 255.255.255.0

перенести на SVI, например,

Код: Выделить всё

 interface vlan 1
 ip address 192.168.173.249 255.255.255.0

и проверить повторяется ли поведение

Re: MES5324, странное поведение линка

Добавлено: 17 окт 2019 13:12
z117

Код: Выделить всё

interface vlan 173
 ip address 192.168.173.249 255.255.255.0

interface tengigabitethernet3/0/24
 switchport access vlan 173


Код: Выделить всё

S   10.0.21.0/24 [1/4] via 192.168.173.250, 00:17:00, vlan 173             
C   192.168.173.0/24 is directly connected, vlan 173                       


Поведение не изменилось.

Re: MES5324, странное поведение линка

Добавлено: 17 окт 2019 13:32
z117
С vlan 1 ведёт себя так же.

Re: MES5324, странное поведение линка

Добавлено: 17 окт 2019 13:52
z117
Иногда, кстати, случается такое:

Код: Выделить всё

console#ping 192.168.173.250
Pinging 192.168.173.250 with 18 bytes of data:

PING: no reply from 192.168.173.250
PING: timeout
18 bytes from 192.168.173.250: icmp_seq=2. time=1840 ms
18 bytes from 192.168.173.250: icmp_seq=3. time=0 ms
18 bytes from 192.168.173.250: icmp_seq=4. time=0 ms

----192.168.173.250 PING Statistics----
4 packets transmitted, 3 packets received, 25% packet loss
round-trip (ms) min/avg/max = 0/613/1840

Re: MES5324, странное поведение линка

Добавлено: 18 окт 2019 13:35
z117
Посмотрел tcpdump, стало понятнее:

Код: Выделить всё

13:19:01.336446 IP (tos 0xe0, ttl 64, id 47646, offset 0, flags [none], proto ICMP (1), length 46)
    192.168.173.249 > 10.0.21.10: ICMP echo request, id 919, seq 1, length 26
13:19:01.337634 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.173.249 tell 10.0.21.10, length 46
13:19:02.337653 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.173.249 tell 10.0.21.10, length 46
13:19:03.337670 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.173.249 tell 10.0.21.10, length 46


Видно, что коммутатор не отвечает на arp-ы. Они приходят от имени 10.0.21.10. Вопрос, кто не прав - MES, что не отвечает, или удалённый компьютер, что шлёт arp-ы не с тем адресом.

Re: MES5324, странное поведение линка

Добавлено: 18 окт 2019 18:51
Aleksey Shimanov
z117 писал(а):Вопрос, кто не прав - MES, что не отвечает, или удалённый компьютер, что шлёт arp-ы не с тем адресом.

MES скорее всего отвечает, вот только шлет ответы на шлюз по умолчанию.

Re: MES5324, странное поведение линка

Добавлено: 19 окт 2019 00:04
z117
Aleksey Shimanov писал(а):MES скорее всего отвечает, вот только шлет ответы на шлюз по умолчанию.

Ну и что с этим делать?

Re: MES5324, странное поведение линка

Добавлено: 21 окт 2019 09:22
Евгений Т
Здравствуйте.

Коммутатор не будет отвечать на арпы, у которых Sender IP не относится к его connected сети. Ведь арп распространяется в пределах одного броадкастового домена. Следует искать причину проблемы на встречной стороне.

Re: MES5324, странное поведение линка

Добавлено: 21 окт 2019 12:21
Aleksey Shimanov
z117 писал(а):
Aleksey Shimanov писал(а):MES скорее всего отвечает, вот только шлет ответы на шлюз по умолчанию.

Ну и что с этим делать?

Прописать маршрут. :D
Если коммутатор подключен к MES, можно на порту прописать ip-адрес или VLAN с нужной подсетью.

P.S. А трассировка какой маршрут выдает?

Re: MES5324, странное поведение линка

Добавлено: 21 окт 2019 16:20
z117
На циске такой фигни не было ;-)

Спасибо, общую идею понял, попробую разные варианты, о результатах отпишусь.

Re: MES5324, странное поведение линка

Добавлено: 21 окт 2019 17:27
Aleksey Shimanov
z117 писал(а):На циске такой фигни не было ;-)

А может на циске OSPF, либо какой другой динамический протокол маршрутизации был настроен, а на Eltex'е не настроен. :P

Re: MES5324, странное поведение линка

Добавлено: 21 окт 2019 20:44
z117
Aleksey Shimanov писал(а):
z117 писал(а):На циске такой фигни не было ;-)

А может на циске OSPF, либо какой другой динамический протокол маршрутизации был настроен, а на Eltex'е не настроен. :P


Нет, конфигурация идентичная. Просто провод переткнули из циски в MES. Маршрут ни при чём, он прописан статически в обоих случаях.

Решили проблему путём включения

Код: Выделить всё

net.ipv4.conf.all.arp_announce = 1

на втором конце линка. В общем-то, логично, но, поскольку с прошлым коммутатором работало, сразу в эту сторону думать не стали.