Перейти к содержимому
Калькуляторы

q1b

Пользователи
 Просмотреть профиль  Активность

  • Публикации

    10

  • Зарегистрирован

  • Посещение

 Тип публикации 

Сообщения, опубликованные пользователем q1b

  1. Опубликовано · Жалоба на ответ

    Ну да, dot1q терминация или qnq, vlan per user это самый оптимальный сценарий для ipoe вообще из всех возможных.

    Я имею в виду не запрос на Radius-сервер с vlan-id, а определение принадлежности пакета к уже существующему CLIPS'у. Т. е. если прилетают пакеты от разных хостов с разными исходящими МАC-адресами, соответственно, но в одном VLAN'е, как они будут классифицироваться? Будут они относиться к одному CLIPS'у?

  2. Опубликовано · Жалоба на ответ

    Откуда вообще вы взяли эти clips groups. В документации такого не вижу.

    http://rbdoc.ufanet.ru/en_lzn7830011_1_r1a/63_1543-CRA1191170_1Uen.A.html

    Скорей всего для шейпинга кучки ip у одного абонента вам нужно Dynamic CLIPS on dot1q On-Demand PVCs.

    То есть принадлежность к CLIPS'у определяется по vlan id, а не по MAC-адресу?

  4. Опубликовано · Жалоба на ответ

    Интересует вопрос по CLIPS Groups в Redback. Может кто объяснить, какую функция выполняет эта возможность на маршрутизаторе? Есть ли у кого-нибудь реальный случай ее применения?

    И еще интересует вопрос общего шейпинга CLIPS'ов. То есть имеем, скажем, 5 активных clips'ов, есть ли возможность на SE шейпить их как один поток? Для этого ли дана группировка clips'ов?

  5. Опубликовано · Жалоба на ответ

    Вообще вся изначальная задача была создать GRE-туннель с MTU 1500, что на выходе выдавало MTU больший 1500 вне туннеля, и приходилось фрагментировать на уровне IP. В конечном итоге все это дело завернул в L4-туннель, чем избавился от L3-фрагментирования.

     

    Всем обсуждавшим данную тему большое спасибо.

  7. Опубликовано · Жалоба на ответ

    Сейчас все пояню пределельно подробно.

    Имеются 2 хоста, скажем, А и B.

    Мне необходимо отправлять пакеты с нагрузкой больше чем 1500 байт c учетом IP-заголовка. Т. е. мне необходимо фрагментировать пакеты на уровне IP, а не TCP (это к словам о "маршрутизатору вообще покласть на фрагментацию, он работает на уровне ip", спасибо за информацию).

    Далее, оба провайдера на обоих концах разрешают отправку пакетов с МTU больше 1500, проверял пингом командой "ping -s 1600 GW_A" и "ping -s 1600 GW_B". Tcpdump показывает, что пакеты удачно фрагментируются собираются у шлюзов, снова фрагментируется, отправляются и собирается на моем сервере.

     

    Но когда я отправляю аналогичный пинг с хоста A на хост B, конечный хост B получает лишь первую часть пакета. Нагляднее:

    Отправляет хост А

    04:53:20.723446 IP host_A > host_B: ICMP echo request, id 5730, seq 3, length 1480
04:53:20.723467 IP host_A > host_B: ip-proto-1
04:53:21.731443 IP host_A > host_B: ICMP echo request, id 5730, seq 4, length 1480
04:53:21.731464 IP host_A > host_B: ip-proto-1

    Получает хост B

    11:53:20.753000 IP host_A > host_B: ICMP echo request, id 5730, seq 3, length 1480
11:53:21.761175 IP host_A > host_B: ICMP echo request, id 5730, seq 4, length 1480

     

    Однако в обратном направлении от хоста B к хосту A фрагментированные пакеты доходят все без потерь.

     

    Дальше я сделал tracepath от хоста А к хосту B и получил приблизительно следующую информацию:

     

    1. host_A

    2. GW_A

    3. X1

    3. X2

    4. X3

    5. X4

    6. X5

    7. GW_B

    8. host_B

     

    После пинга с MTU > 1500 с обоих концов было выяснено, что маршрутизатор X3 не отвечает на подобный пинг. Из чего я и сделал вывод, что маршрутизатор X3 не передает фрагментированные пакеты.

    Теперь повторяю вопрос: "обязан ли этот маршрутизатор по стандарту разрешать фрагментацию пакетов или это делается исключительно по желанию администраторов?"

     

    Если мои анализы где-то неверны, прошу поправить.

  8. Опубликовано · Жалоба на ответ

    Доброго времени суток всем! Ситуация такая: есть два сервера, находящихся географически в разных точках и имеющих связь через Интернет. Им необходима передача данных c фрагментацией на уровне IP. На всей цепочке маршрутизаторов все кроме одного маршрутизатора разрешают фрагментацию. Вопрос: обязан ли этот маршрутизатор по стандарту разрешать фрагментацию пакетов или это делается исключительно по желанию администраторов?

  9. Опубликовано · Жалоба на ответ

    надо юзать IS-IS для динамической маршрутизации между ними

    Насчет IS-IS понял. А зачем тогда connected-маршрут на таких интерфейсах, если этот интерфейс в дальнейшем ни на один порт навесить нельзя? Меня больше интересует их "lan" взаимодействие, нежели маршруты вне сети.

    Правильно ли я понимаю, что lan и id сделаны для разграничения области действия IS-IS? Только для этого?

  10. Опубликовано · Жалоба на ответ

    Всем доброго времени суток!

    Я имею Ericsson SE600 с версией прошивки SmartEdge OS Version SEOS-12.1.1.11-Release.

     

    При конфиге:

    Global:

    service multiple-contexts
!
service inter-context routing

     

    Имеем два контекста с одним интерфейсом на каждом:

    context1:

    context context1
!
interface in1 intercontext lan 1
 ip address 192.168.0.1/24
!

     

    context2:

    context context2
!
interface in2 intercontext lan 1
 ip address 192.168.0.2/24
!

    При данной конфигурации интерфейсы из двух контекстов друг друга не видят (не пингуются). При этом имеют один id на интерфейсе. Между ними связь появляется после создания роута типа:

    ip route 192.168.0.1/32 context context1

    Объясните пожалуйста смысл таких интерфейсов, если для каждого хоста необходимо прописывать статический роут. Такой же результат можно получить используя interface loopback. Зачем выделять маску под сеть, если в дальнейшем она непригодна? Зачем указывается отдельный id на интерфейсе, если они и без того друг друга видят?

     

    Поясните пожалуйста, как заставить их видеть друг друга, используя connected маршрут интерфейса?

    ...
> C     192.168.0.0/24                        0         0  04:38:01  in1