Jump to content
Калькуляторы

q1b

Пользователи
  • Content Count

    10
  • Joined

  • Last visited

About q1b

  • Rank
    Абитуриент
  1. Я имею в виду не запрос на Radius-сервер с vlan-id, а определение принадлежности пакета к уже существующему CLIPS'у. Т. е. если прилетают пакеты от разных хостов с разными исходящими МАC-адресами, соответственно, но в одном VLAN'е, как они будут классифицироваться? Будут они относиться к одному CLIPS'у?
  2. http://rbdoc.ufanet.ru/en_lzn7830011_1_r1a/63_1543-CRA1191170_1Uen.A.html То есть принадлежность к CLIPS'у определяется по vlan id, а не по MAC-адресу?
  3. Интересует вопрос по CLIPS Groups в Redback. Может кто объяснить, какую функция выполняет эта возможность на маршрутизаторе? Есть ли у кого-нибудь реальный случай ее применения? И еще интересует вопрос общего шейпинга CLIPS'ов. То есть имеем, скажем, 5 активных clips'ов, есть ли возможность на SE шейпить их как один поток? Для этого ли дана группировка clips'ов?
  4. Вообще вся изначальная задача была создать GRE-туннель с MTU 1500, что на выходе выдавало MTU больший 1500 вне туннеля, и приходилось фрагментировать на уровне IP. В конечном итоге все это дело завернул в L4-туннель, чем избавился от L3-фрагментирования. Всем обсуждавшим данную тему большое спасибо.
  5. И да, выразился некорректно, речь идет о передаче уже фрагментированных пакетов.
  6. Сейчас все пояню пределельно подробно. Имеются 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 не передает фрагментированные пакеты. Теперь повторяю вопрос: "обязан ли этот маршрутизатор по стандарту разрешать фрагментацию пакетов или это делается исключительно по желанию администраторов?" Если мои анализы где-то неверны, прошу поправить.
  7. Доброго времени суток всем! Ситуация такая: есть два сервера, находящихся географически в разных точках и имеющих связь через Интернет. Им необходима передача данных c фрагментацией на уровне IP. На всей цепочке маршрутизаторов все кроме одного маршрутизатора разрешают фрагментацию. Вопрос: обязан ли этот маршрутизатор по стандарту разрешать фрагментацию пакетов или это делается исключительно по желанию администраторов?
  8. Насчет IS-IS понял. А зачем тогда connected-маршрут на таких интерфейсах, если этот интерфейс в дальнейшем ни на один порт навесить нельзя? Меня больше интересует их "lan" взаимодействие, нежели маршруты вне сети. Правильно ли я понимаю, что lan и id сделаны для разграничения области действия IS-IS? Только для этого?
  9. Всем доброго времени суток! Я имею 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