Le ecureuil
-
Постов
11 068 -
Зарегистрирован
-
Посещение
-
Победитель дней
648
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Весь контент Le ecureuil
-
MTU у них одинаковый, но это интерфейсы разного рода. EoIP - это L2-интерфейс, потому вам еще нужно отнять 12 байт L2-заголовка, итого будет 1404 в классическом понимании MTU на уровне L3. Gre и IPIP - это L3-интерфейс, у них будет 1416 байт. Руками можно выставить MTU у EoIP более, чем 1416, например даже 1500, но при этом фреймы L2 размером более чем 1416 байт проходить все равно не будут - EoIP не поддерживает фрагментацию и сборку, это особенность протокола. Такие пакеты просто будут отброшены. Еще вариант - туннельный IPsec между 2-1 и 1-3, и дальше уже туннель 2-3. Однако overhead при этом будет сравним.- 1 ответ
-
- 1
-
-
@tripleNAT Скидывайте свои настройки Mikrotik, проверим.
-
Технически это не баг в mppe, это особенность работы в режиме, когда MTU роута меняется.
-
Это не баг, а изначально заложенная фича. При редактировании порядок полностью сохраняется, потому если надо добавить в начало - нужно пересоздать весь список.
-
Представленной информации мало для дальнейших действий, вам нужно пообщаться с настройщиком Cisco.
-
Начните с: Идентификатор локального шлюза - IP-адрес Значение идентификатора - IP-адрес вашего WAN Идентификатор удаленного шлюза - IP-адрес Значение идентификатора - IP-адрес Cisco Версия протокола - IKEv1
-
PPTP же есть o_O
-
Да, это нормально. Подобные пакеты отмечаются особой маркой, и сам WiFi драйвер их внутри себя уничтожает, не давая им вылетать в воздух. При этом в захвате они видны. Так сделано специально, чтобы при отправке на bridge пакеты уходили на провод нормально, а воздух их резал, независимо от того, кто и в каком объеме включен в bridge. Попробуйте захватить эфир WiFi, и вы увидите, что их там нет.
-
В модеме вам нужно прописать роут в домашнюю сеть через USB Keenetic. Ну или ставить proxy, ну или делать NAT.
-
Для 6856 2.08 пока еще не собран в delta.
-
Даже в linux-next этот код не изменен, значит на то есть причины.
-
"Talk's cheap, show us the code!" https://github.com/ndmsystems/linux-3.4/blob/master/net/netfilter/xt_TCPMSS.c#L132
-
Virtual-IP сейчас не рассчитывается, поскольку при таком типе туннеля не создается отдельного интерфейса для задания MTU. Но там стоит TCP MSS PMTU Clamp + юзер волен в консоли задать любое значение Clamp руками.
-
В этой статье не учитывается размер L2TP и NAT-T Encap заголовков, потому там есть неточности. Однако суть верна, будет использоваться самое оптимальное значение из возможных.
-
@r13 спасибо за репорт, поправлю. А не напомните тему и пост, где обсуждалось активное соединение в качестве source? Ну для порядка, чтобы восстановить нить обсуждения.
-
Будет сделан автоматический расчет на основе MTU интерфейса, через который пойдет соединение. Если у вас все пойдет через IPoE с 1500, то значение будет одно, если через PPTP с VLAN, то другое.
-
Купите девайс за 15к?
-
Всем юзерам: не забудьте про , иначе счетчик будет показывать погоду на Марсе в случае наличия ppe hardware.
-
А у вас точно нет NAT между PPTP и домашней сетью?
-
Сделано
-
сделать так, чтобы - ifTable/IfDescr - бралось из ID - ifXTable/ifName - бралось из rename (если непустое, иначе ID) - ifXTable/ifAlias - бралось из description (если непустое, иначе rename) пойдет?
-
При работе через NAT, а также при недоступности 500 порта клиент автоматом переходит на 4500.
-
Попробуйте написать.