fet4
-
Всього повідомлень
538 -
Приєднався
-
Останній візит
-
Дней в лидерах
1
Тип контенту
Профили
Форум
Календарь
Сообщения додав fet4
-
-
Кто обновлял загрузчик удаленно?
-
1 час назад, ttttt сказал:
ARP ответы там не хитрые, а обычные, просто с помощью этих ответов мы загоняем клиентов либо в один шнурок либо в другой, никакой магии. Проще ничего в принципе нет, не придумывайте.
Так вы пробовали данный вариант?
-
Предложите ближайшую замену, которая решит вопрос.
-
Цитата
Лучше LACP или статическую агрегацию поднять, сейчас все свитчи ее умеют.
Дело в том что сейчас так и работает, но работает не так как нужно мне.
Мой edge core 4612 не позволяет менять тип хеширования и он равен EtherChannel, на основе хэш-функции над MAC-адресом, IP-адресом или TCP и UDP портом источника или получателя.
В итоге если сравнить два графика, двух портов с этого ЛАГ, то исход с маршрутизатора равномерно балансируется, а вот вход на него идет с большим перекосом. Маршрутизатор выполняет роль браса, там Л2 (pppoe,ipoe) и по идее нужно использовать хэш-функцию только над MAC-адресом, а не IP.
Кстати есть еще бордер на этом же свиче там уже Л3 и на нем все в порядке что и подтверждает что для Л2 трафика неправильный хэш.
ЦитатаА чем это костыльно? Наоборот же, эффективный и дубовый способ достичь распределения трафика.
Вы пробовали?
-
Привет всем.
Кто-то использовал бондинг в режиме balance-alb?
Если да, расскажите конфигурацию? На свитче нужно настраивать агрегацию?
-
Вы знаете у меня олт перегружался даже когда я ip прописывал в неправильном формате на онушку.
-
А кто изменял формат строки circuit-id ?
Сейчас такое прилетает
Circuit-ID 00:06:00:65:00:01:00:0b:01:06:00:e0:b1:be:0b:d9 Remote-ID 00:06:00:e0:b1:be:0b:d9А хотелось бы типа такого
Circuit-ID 00:04:00:65:00:02 Remote-ID 00:06:dc:d2:fc:5c:bf:e8 -
Прошейся на 46085. Сам использую эту прошивку уже 2 месяца, полет нормальный. Перешивался так же по причине глюков.
-
В переинициализации сессии в разумный срок тоже ничего страшного нет
Не знаю как у вас, а у нас через минуту пропажи канала уже 30 человек в телефонной очереди. Ну и как-бы пережить 5-минутный лизтайм еще как-то можно, если-бы отвалившийся брас всегда отваливался физически, а такое далеко не всегда. Чаще физические линки браса не падают, оспф маршруты не перестраивает и приходится пинать все ручками.
У меня по крону, раз в минуту пингом в 30 запросов/ответов проверяются 2 канала т.к. бгп нет. За минуту люди не успевают начать звонить если один отвалился и все переключились на другой, возможно у Вас больше клиентов. Раньше стояло раз 5 мин., тогда уже появлялись звонки и то не страшно, в принципе такие падения канала как и браса явления не частые в этом ничего страшного нет я считаю, это естественный рабочий процесс.
Чаще физические линки браса не падают, оспф маршруты не перестраивает и приходится пинать все ручками.Немного не понял. Если есть два браса по оспф с бордером и не только, один брас вышел из строя (выключился,завис и т.д.) в любом случае его маршруты удалятся с других, а когда произойдет переинициализация сессий на втором брасе эти же маршруты появятся только уже через via брас_2 и руки не нужны.
-
Поддержу pablabor, хотя я сам тоже за простоту, за чистый ethernet в том виде в каком он придуман, без лишних "надстроек", но интересно бы было увидеть это горячее переключения, даже Вас послушал бы о достижениях в данной области
, интересный ход мысли, т.к. мысли об этом были и если Вы это реализовали у себя то Вы молодец!Вообще стандарта ipoe как такового нет, кто как хочет так и крутит. pavlabor так, другой по-другому кто как видит так и делает. кому как проще. Но все так спорят, доказывают свою точку зрения как будто должно быть так и не иначе, аж страшно
В переинициализации сессии в разумный срок тоже ничего страшного нет, bgp тоже у выше стоящих перестраивается иногда, тоже дропы проскакивают. Поэтому все относительно как по мне.
-
А вот разделять терминацию и NAT - идеалогически правильно, схема получается проще и лучше масштабируемой.
Как по мне это вообще единственный правильный вариант когда с трафиком работаешь в плотную. qos, шейпинг, nat и т.д. не реально сделать на одной тачке адекватными способами, приходится изощряться разными способами imq,ifb, маркировки, патчинги и т.д. а это уже костыли. А когда это разделено как минимум на 2 тачки, архитектура управления трафиком становится прозрачней и понятней в разы.
На железные решения пока смотрю косо т.к. голый Linux удовлетворяет почти полностью и в принципе стабилен, бывают конечно и приколы, например месяц назад NAT на 4.9 начал выпадать в кернел паник проработавши месяц, обновил на 4.14 стабилизировался.
Есть так же accel на 4.14 по стабильности пока не скажу только неделю ввел в эксплуатацию, на 3.18 работал хорошо.
-
Зачем вы разводите этот диалог? вы о чем вообще? у нас в стране бывают райские условия на каких то провайдерах? приведите примеры. 6 дней в неделю это нормальная рабочая неделя или вы знаете что то чего не знаю я. Гроза? У вас наверное был опыт медных пешек по фасаду. Вот вам и не повезло. У меня лично последний выгоревший порт был несколько лет назад. Все в основном идет внутри помещений. Работал в очень многих провайдерах в своем городе и много знакомых осталось и не помню ни одного случая когда кто-то жаловался у нас в городе на грозы. Разве что в начале 2000 когда была 100% медь. Поэтому если у вас неприязнь к данной профессии так и скажите, что лазить по чердакам вызывает у вас неприязнь. А про "рабы" не пишите. Уверен вы знаете положение в стране и с уровнем зарплат. Поэтому 6 дней в неделю по 3-9 часов в день с ЗП 10-15 тыс это очень даже неплохо.
Не смешите мои тапочки.
Что я видел по Ленинском району, не думаю что в других районах что-то другое.
А именно:
- 70% идет сраная белая витуха в окно по крыше обмотанная об Ваши магистрали оптические, тупо сопли по которым стекает вода в порты клиентам. Не знаю как еще жильцы терпят это.
- 70 % ящиков открыты и обмотаны той же витухой никакой культуры монтажа ни на крыше ни в подъезде.
- почти все rj-45 обжаты на жилы и вставлены в натянутом виде.
-2-3 порта точно горелые.
Снимите розовые очки.
-
Чувак выставь тех. задание и найдутся те кто его выполнит, а если не выполнит он будет в "плохом свете" как сейчас ты. На форуме тоже помогут, но нужно с конкретными вопросами обращаться и показывать, что делал и что не получилось.
-
После этой строчки ip dhcp-relay snooping db-file
Должна быть табличка, а ее нет.
Осмелюсь предположить, что функционал не работает.
Почему она должна быть? Он же пишет
/dhcpr-database
Вы об этой ?
#show ip dhcp-relay snooping binding Hardware Address IP Address Surplus Time Type VLAN Intf ----------------- --------------- ------------ ------- ---- ---------- d4:6e:0e:53:d5:2d 10.194.132.24 960 DHCP_SN 132 epon0/4 c4:6e:1f:61:ca:f1 10.194.132.5 1020 DHCP_SN 132 epon0/4 b4:74:43:7b:71:67 10.194.130.49 1380 DHCP_SN 130 epon0/2 18:a6:f7:3b:c1:71 10.194.129.20 1020 DHCP_SN 129 epon0/1 f4:f2:6d:3c:dc:91 10.194.130.10 1020 DHCP_SN 130 epon0/2 d4:6e:0e:96:5f:d5 10.194.132.9 900 DHCP_SN 132 epon0/4 c0:25:e9:ce:9d:c9 10.194.132.20 960 DHCP_SN 132 epon0/4 f4:f2:6d:5c:27:a7 10.194.129.14 1260 DHCP_SN 129 epon0/1 a0:f3:c1:13:ee:fd 10.194.129.22 1200 DHCP_SN 129 epon0/1 30:b5:c2:5a:3e:55 10.194.132.13 1020 DHCP_SN 132 epon0/4 10:fe:ed:59:3f:35 10.194.129.10 1680 DHCP_SN 129 epon0/1 50:c7:bf:6b:4c:86 10.194.132.6 1740 DHCP_SN 132 epon0/4 e4:8d:8c:ca:b8:3e 10.194.130.5 1260 DHCP_SN 130 epon0/2 f4:6d:04:8c:90:fc 10.194.129.8 1020 DHCP_SN 129 epon0/1 14:cc:20:0a:fd:26 10.194.129.43 960 DHCP_SN 129 epon0/1 c0:25:e9:bd:fe:a3 10.194.132.7 1260 DHCP_SN 132 epon0/4 ...
Что бы Вы поверили
#show ip dhcp-relay snooping statistics server forward from trusted port: 172274 client forward to trusted port: 183859 server drop received on untrusted port: 18 client drop destination on untrusted port: 0 client drop untrusted option 82 field: 0 client drop bad DHCP release request: 0 client drop failed verify MAC check: 0 client drop max client check: 0 Vlan 129: The current client:45 Vlan 130: The current client:29 Vlan 131: The current client:31 Vlan 132: The current client:50
-
To argus78:
Dhcp snooping еще та лажа. У себя отключил давно и все полетело.
Ппоблема за 128 не заключается в функционале снупинга, а заключается в ткамовской таблице. Ну очень мало в ней мозгов.
Как вы авторизуете клиента?
#show ip dhcp-relay snooping ip dhcp-relay snooping ip dhcp-relay snooping vlan 129-132 ip arp inspection vlan 129-132 ip verify source vlan 129-132 ip dhcp-relay snooping log DHCP Snooping trust interface: g0/1 ARP Inspect trust interface: g0/1 IP source guard trust interface: g0/1 DHCP Snooping deny interface: ip dhcp-relay snooping db-file /dhcpr-database
-
Не понял тогда вашего вопроса - "А они работают?"
-
О. Спасибо. Надо обратить внимание на версию прошивку. У меня 2 порта полные, а два процентов на 90 забиты.
Пока не убрал снупинг - 100%
Вы извините, я не хочу никого обидеть, а они работают?
Работают, очищаю периодически не используемые ОНУ.
На 33463 цпу так же был в полке потери на олт были огромные, видимо из-за этой проблемы.
-
Отключите DHCP SNooping, DAI и ISG.
Должно отпустить. А потом по одному врубайте.
То, что вы прочитали про 128 абонов - это чистейшая правда
Отключите DHCP SNooping, DAI и ISG.
Должно отпустить. А потом по одному врубайте.
То, что вы прочитали про 128 абонов - это чистейшая правда
Две полные головы по дхцп. Прошивка 46085. Нет вышеописанных проблем. Опции включены.
-
Повторюсь - до головы 100км ехать надо. Хотелось сделать удаленно, но нужно проверенное решение. Потому и спросил, может кто знает.
Скачай startup-config удали с него все кроме нужных конфигураций для доступа к коммутатору vlan,ip,interfaces и тд. Удали все кроме switch.bin и tiger.blob и залей отредактированный startup-config. reboot
-
Удали все кроме switch.bin и tiger.blob. перезагрузить.
-
Да я ошибся, есть круглый диэлектрик 2.7 кн ОКТ-д. Рассчитан до 180м
-
Окадт 2.7кН выдержит все 200м, вы б его видели. Берите не пожалеете, гораздо легче троса на данной прочности.
-
Version 10.1.0E 33463 не бывает. только BD_3310C_10.1.0D_33463_en.bin скорей всего это лишь их внутренняя нумерация.
Я думаю ничего не произойдет если вы перешьете вниз. Я так делал.
Но я бы советовал сразу шить BD_3310C_10.1.0E_46085_en.bin
-
Прошивка 46085 решает вопрос с загрузкой cpu, иных косяков не было замечено.
, интересный ход мысли, т.к. мысли об этом были и если Вы это реализовали у себя то Вы молодец!
Переезд с 3310 на 36ХХ
в PON
Опубліковано:
Т.е. с рабочих 3310 берем конфиги ону и на тестовом 36xx вбиваем mac=llid на нужном порту и вносим конфиги без включенных онух, не меняя epon onu-authen-method ?