Коллеги, как вы полагаете, имеет-ли право на существование схема подключения абонента, при которой он: 1) поднимает PPP-соединение с public network 2) поверх этого соединения поднимает L2TP до корпоративного впн-концентратора то есть получается (IP over (PPP inside L2TP)) over PPP и я чувствую большую задницу в этом множестве инкапсуляций/декапсуляций - как с точки зрения MTU/etc, так и с точки зрения эффективности использования пропускной полосы... Any comments on this? Спасибо -- /doka ~~~~~~~~ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/ "Справа не в церкві і не в наркотиках. Справа у відповідальності та вдячності. Якщо в тебе це є, маєш шанс померти не останньою скотиною." (с) С.Жадан, "Ворошиловград"
Vladimir Litovka wrote:
Коллеги,
как вы полагаете, имеет-ли право на существование схема подключения абонента, при которой он:
1) поднимает PPP-соединение с public network 2) поверх этого соединения поднимает L2TP до корпоративного впн-концентратора
то есть получается (IP over (PPP inside L2TP)) over PPP и я чувствую большую задницу в этом множестве инкапсуляций/декапсуляций - как с точки зрения MTU/etc, так и с точки зрения эффективности использования пропускной полосы...
Any comments on this?
Спасибо
Есть опыт до 3 инкапусаляций , возникают проблемы с MTU особенно с multicast протоколами которые не позволяют делать фрагментацию . В принципе если на итерфейсах расставить соответствующие значения MTU - TCP протоколы будут отлично работать . Потери полосы от 10 до 25% (интуитивно :) ) .
On 28.03.2011 15:23, Alexandr Turovsky wrote:
как вы полагаете, имеет-ли право на существование схема подключения абонента, при которой он:
1) поднимает PPP-соединение с public network 2) поверх этого соединения поднимает L2TP до корпоративного впн-концентратора
то есть получается (IP over (PPP inside L2TP)) over PPP и я чувствую большую задницу в этом множестве инкапсуляций/декапсуляций - как с точки зрения MTU/etc, так и с точки зрения эффективности использования пропускной полосы...
Есть опыт до 3 инкапусаляций , возникают проблемы с MTU особенно с multicast протоколами которые не позволяют делать фрагментацию . В принципе если на итерфейсах расставить соответствующие значения MTU - TCP протоколы будут отлично работать . Потери полосы от 10 до 25% (интуитивно :) ) .
Что вы такие ужасы рассказываете? Первое PPP (если это Serial/Async/etc) может вообще не уменьшить "доступный MTU" , L2TP заберет до 46 байт (офигенный, кстати, overhead, по сравнению с другими туннельными протоколами), итого, от 1500 останется 1454 байта, или 3% потери полосы, что мизер даже по меркам 10-ти летней давности. TCP обычно, даже с поломанным PMTU Discovery прекрасно лечится "ip tcp adjust-mss" и аналогами. Да, есть вероятность, что поломаются какие-то проприетарные протоколы, multicast с пакетами в 1500 байт и т.п., но они точно так же поломаются на любом туннеле, PPPoE и т.п. -- Vladimir N. Garnick [nic-hdl: VG-RIPE, VG-UANIC]
Спасибо То есть, похоже, будет работать, а малтикаст - ну то дело такое... я немного корпоративных сетей видел, где бы малтикаст использовался. А если используется, то обычно есть его копия в юникасте. On 3/28/2011 3:50 PM, Vladimir Garnick wrote:
On 28.03.2011 15:23, Alexandr Turovsky wrote:
как вы полагаете, имеет-ли право на существование схема подключения абонента, при которой он:
1) поднимает PPP-соединение с public network 2) поверх этого соединения поднимает L2TP до корпоративного впн-концентратора
то есть получается (IP over (PPP inside L2TP)) over PPP и я чувствую большую задницу в этом множестве инкапсуляций/декапсуляций - как с точки зрения MTU/etc, так и с точки зрения эффективности использования пропускной полосы...
Есть опыт до 3 инкапусаляций , возникают проблемы с MTU особенно с multicast протоколами которые не позволяют делать фрагментацию . В принципе если на итерфейсах расставить соответствующие значения MTU - TCP протоколы будут отлично работать . Потери полосы от 10 до 25% (интуитивно :) ) .
Что вы такие ужасы рассказываете?
Первое PPP (если это Serial/Async/etc) может вообще не уменьшить "доступный MTU" , L2TP заберет до 46 байт (офигенный, кстати, overhead, по сравнению с другими туннельными протоколами), итого, от 1500 останется 1454 байта, или 3% потери полосы, что мизер даже по меркам 10-ти летней давности.
TCP обычно, даже с поломанным PMTU Discovery прекрасно лечится "ip tcp adjust-mss" и аналогами. Да, есть вероятность, что поломаются какие-то проприетарные протоколы, multicast с пакетами в 1500 байт и т.п., но они точно так же поломаются на любом туннеле, PPPoE и т.п.
-- /doka ~~~~~~~~ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/ "Справа не в церкві і не в наркотиках. Справа у відповідальності та вдячності. Якщо в тебе це є, маєш шанс померти не останньою скотиною." (с) С.Жадан, "Ворошиловград"
participants (3)
-
Alexandr Turovsky -
Vladimir Garnick -
Vladimir Litovka