[Ivan_83]

Работает!!! Вообще netgraph конечно вещь!! Без нее никак в данной ситуации, ибо я не нашел других способов перекидывать LACPDU через бридж.

Я не очень понял зачем на R2 и R3 было делать ядрёно-сокетное проксирование, там или роутингом или в худшем случае форвадом пакетов средствами фаера можно было обойтись.

 

Я поглядел в исходниках ieee8023ad_lacp.h , там вроде есть упоминание LACP_FAST_TIMEOUT_TIME и LACP_SLOW_PERIODIC_TIME, но как реально поменять значения я не знаю.

Не интересовался даже, но чисто для себя обычно можно быстро накидать патч заменяющий константы на статические переменные, которые доступны для изменения через sysctl, строчек по 5 кода на одну переменную, не больше.

[tt128]

Всем привет.

 

Сумеете оформить статью на хабре?

 

Можно подумать в принципе, почему нет...

 

Я не очень понял зачем на R2 и R3 было делать ядрёно-сокетное проксирование, там или роутингом или в худшем случае форвадом пакетов средствами фаера можно было обойтись.

 

Согласен можно все было решить роутингом, но нужен был именно L2 , и в качестве эксперимента поднятие LACP.

Это скорее ради выяснения принципиальных возможностей...

 

Но собственно продолжаем тему. Не все так гладко как хотелось бы, после некоторого времени тестирования такой конфигурации, наткнулись на проблему скорее всего связанную с MTU и битом DF.

Выглядит это так как будто часть траффика пролезает в канал (ICMP, SMTP, GRE итд...), а часть нет (SSH например отваливается по таймауту так и не спросив пароль.)

Я вот пытаюсь понять, что именно происходит с MTU при прохождении R2 - R3 когда netgraph перекидывает пакетики из туннеля в туннель ??

Собственно на всех ифейсах и физических и ngethX стоит MTU 1500. Подозреваю что его надо менять.

 

Когда такую же конфигурацию мы собирали на OpenVPN - L2 udp туннелях то там была опция link-mtu 1533, без нее была очень похожая ситуация.

Есть у кого-нибудь мысли по этому поводу??

[vlad11]

 

Когда такую же конфигурацию мы собирали на OpenVPN - L2 udp туннелях то там была опция link-mtu 1533, без нее была очень похожая ситуация.

Есть у кого-нибудь мысли по этому поводу??

 

Я давно на выходе через нетграф и tcpmss поджимаю MSS до 1440.

[Ivan_83]

Согласен можно все было решить роутингом, но нужен был именно L2 , и в качестве эксперимента поднятие LACP.

У тебя л2 внутри л4 пакетов. Промежуточные узлы внутрь ип пакетов не полезут если дст адрес не их.

 

Но собственно продолжаем тему. Не все так гладко как хотелось бы, после некоторого времени тестирования такой конфигурации, наткнулись на проблему скорее всего связанную с MTU и битом DF. Выглядит это так как будто часть траффика пролезает в канал (ICMP, SMTP, GRE итд...), а часть нет (SSH например отваливается по таймауту так и не спросив пароль.) Я вот пытаюсь понять, что именно происходит с MTU при прохождении R2 - R3 когда netgraph перекидывает пакетики из туннеля в туннель ?? Собственно на всех ифейсах и физических и ngethX стоит MTU 1500. Подозреваю что его надо менять.

tcpdump посмотри что происходит.

Притом один на физ интерфейсе а второй на нетграфовом.

ping тебе в помощь, указываешь размер пакета максимальный и смотришь что происходит.

А происходить должно следующее: по идее должно прилетать на каждый пинг 2 юдп пакета: один забитый под завязку второй почти пустой.

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