[alibek]

Столкнулся со странной проблемой.

Есть у меня некоторые клиенты, которые подключаются по выделенной линии; это абоненты-ЮЛ, каждый в своем VLAN, с выдачей публичных /30 на подключение.

Раньше они были подключены на Cisco 7201, примерно таким образом:

interface GigabitEthernet0/1.xxx
encapsulation dot1Q xxx
ip address aa.aa.aa.25 255.255.255.252
rate-limit input 1000000 83333 166666 conform-action transmit exceed-action drop
rate-limit output 1000000 83333 166666 conform-action transmit exceed-action drop

 

Сейчас все такие абоненты переведены на Ericsson SE100, примерно таким образом:

context local
interface VLANxxx
 ip address aa.aa.aa.25/30
port ethernet 2/16
encapsulation dot1q
dot1q pvc xxx
 bind interface VLANxxx local
 qos policy policing RATE-1000-IN
 qos policy metering RATE-1000-OUT

Таких абонентов у меня несколько десятков и в настоящий момент почти все они работают нормально.

Были проблемы у двух абонентов, но они решились.

Но теперь появился еще один абонент, еще более странный.

 

У абонента используется Cisco 892.

С момента переключения на SE100 у него время от времени (примерно через 40 минут) перестает работать интернет.

После перезагрузки Cisco 892 по питанию все снова работает некоторое время.

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

С моей стороны я проблем тоже не вижу — линк на коммутаторе не пропадает, MAC-адрес на ядро приходит, в логах коммутаторов и SE100 чего-либо странного нет.

В момент проблем PE пингуется, CE не отвечает.

 

Пробовал менять порт, переключать в другой узел доступа, разницы нет.

Сейчас еще попробую поменять VLAN и IP, хотя и сомневаюсь, что это что-то изменит.

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

 

Что еще можно посмотреть?

[vurd]

Похоже на какую-то проблему в ARP. Чувствую что где-то здесь надо искать. Вам бы поснифать, что там в канале этом происходит, когда абонент в дауне.

 

p.s. А как решили проблему с двумя предыдущими? Там тоже мистика была же.

[alibek]

В одном случае была моя ошибка, не прописал vlan между брасом и ядром (был уверен, что прописывал диапазоном). А со вторым так и не прояснилось, абонент поменял роутер и заработало.

Но там хоть была определенность - не работало совсем.

А тут работает и выключается.

Я тоже про arp думаю, но нет идей, с чего бы начать. 40 минут, после которых пропадает связь, вообще ни в какие таймауты не попадает.

[g3fox]

У нас была похожая проблема, как раз связанная с ARP и Cisco. Циска не отвечала на арп, если запрос шёл не с адреса в её connected сети.

Наш роутер слал ARP то ли с 0.0.0.0 то ли с другого адреса, который бал первым на интерфейсе.

 

У вас в ARP таблице есть запись для абонента?

 

Попробуйте выкинуть влан абонента куда-нибудь на программный роутер, и там собрать дамп.

[alibek]

Ну у меня то сеть connected.

И в ARP-таблице браса записи есть:

#sh arp-cache 195.209.125.146
Host              Hardware address    Ttl    Type  Circuit            
xxx.yyy.125.146   10:05:ca:1e:05:f4   2761   ARPA  2/16 vlan-id 836   

Правда TTL странный, но это скорее всего не хопы, а секунды.

 

Вчера вечером абонента подключил другим маршрутом.

И вроде бы за ночь интернет не пропадал.

Разница в том, что раньше между коммутатором доступа и ядром был коммутатор QTECH QSW-3200, а теперь его нет.

И поскольку 3200 у QTECH это модель очень неудачная и он пару раз впечатлял меня своими глюками, я думаю что причиной был он.

[Andrei]

Циска у клиента наверняка НАТит внутреннюю сетку. Может у нее таблица НАТ-трансляций переполняется и проц тупо уходил в 100% загрузку?

Сделать ограничения типа

ip nat translation timeout 20

ip nat translation tcp-timeout 120

ip nat translation udp-timeout 60

ip nat translation dns-timeout 80

ip nat translation icmp-timeout 10

ip nat translation max-entries 40000

ip nat translation max-entries all-host 400

[alibek]

Может у нее таблица НАТ-трансляций переполняется и проц тупо уходид в 100% загрузку?

Московский тех.отдел у абонента вроде бы грамотный, он бы это заметил.

Впрочем версия неплохая, попрошу проверить.

[g3fox]

Ну у меня то сеть connected.

Я понимаю, что connected. У нас тоже была connected, однако это не мешало роутеру выбирать "не тот" адрес в кач-ве src.

 

И в ARP-таблице браса записи есть:

#sh arp-cache 195.209.125.146
Host              Hardware address    Ttl    Type  Circuit            
xxx.yyy.125.146   10:05:ca:1e:05:f4   2761   ARPA  2/16 vlan-id 836   

Да, ттл в секундах.

Это вывод во время проблемы?

Ну и я бы попробовал зеркальнуть трафик абона, если имеются такие непонятки.

[alibek]

Это вывод во время проблемы?

Нет, сейчас все работает.

Скорее всего чудил QTECH QSW-3200.

Он мне уже попил крови несколько раз. То один раз при включенном dhcp-снупинге и PPPoE+ аккуратно резал PPPoE PADI, не трогая более ничего. То гасил линк на оптическом порту, но при этом в консоли показывал, что линк есть, причем shutdown/no shutdown не помогал, нужно было физически вытащить и вставить SFP.

Снял его нафиг.

[Tosha]

Один раз у нас была чудесная вещь. Циска, когда таймаутятся ARP записи, слала ARP запрос unicast а одно умное оборудование не признавала что ARP запрос может быть не broadcast (Motorola Canopy если кому интересно).

 

Вылечили (а точнее объехали на кривой козе это баг) заданием чудовищно большого времени жизни ARP записей.

 

Дампите трафик и смотрите кто там кого о чем спрашивает и как именно.

[g3fox]

слала ARP запрос unicast

 

Не понял... как такое может быть? Что было в кач-ве dst-mac и dst-ip ?

[Sergeylo]

Аналогично лечили какую-то мутную проблему выкрчиванием arp timeout до малых значений.

[Tosha]

Не понял... как такое может быть? Что было в кач-ве dst-mac и dst-ip ?

dst-mac был mac, на котором только что был dst-ip.

Ну то еcть не традиционный для arp запроса "FF:FF:FF:FF:FF:FF"

 

Возможно еще были какие оптимизации.

Итог - "правильные" arp запросы поступают нерегулярно.

 

Подавляющее количество оборудования работает безупречно. Но бывают странные железки... :)