Потом я пошел в реальную сеть, а конкретнее - пинговать свой dhcp-сервер. К сожалению с ним тоже связи нетСервер опишите (влан, IP-адрес, операционная система, как и куда подключен)
Ведь теперь каждый раз даже при работе из внутри сети клиенты будут нагружать своим трафиком процессор роутера?Да, если только у маршрутизатора обработка NAT не вынесена на специализированный ASIC.
Напомню что изначально задача была в том чтобы организовать доступ к внутрисетевому ресурсу по уникальной паре адрес:порт как с внутри сети так и снаружи.Если использовать DNS-имена в качестве адреса, то вы можете по-разному разрешать их (символьные имена) в IPv4-адреса в зависимости от того, где находится клиент, если у вас свой DNS-сервер. Или на маршрутизаторе, если он поддерживает такую функциональность (DNS doctoring), на лету подменять ответы DNS-сервера, если DNS-сервер чужой.
Это-то понятно, я говорил о том, что клиент может прислать много LSA (которые, как мне известно, с трудом фильтруются), которые сохранятся в LSDB, что утилизирует ресурсы роутера, который еще и другими задачами должен заниматься.
реально с использованием ipvpn или vrf маршрутизация через ospf не вклинивается в сеть оператора. Ну по крайней мере при грамотной настройке route-target-ов)
Так провайдеры не делают.Я надеюсь, что в 2015 году решения планируются с заделом на будущее. Но это не исключает специфики и "нестандартных решений".
ipvpnнапомнили, RIPv2 иногда (все реже и реже) используется в качестве протокола маршрутизации на участке PE-CE (опять же, в случае "деревянного" CE).
И нормально ospf фильтруется,Маршруты - да, а с LSA сложнее. Может получиться, что злонамеренный/неправильно настроенный клиент пришлет вам множество LSA, которые окажутся в вашей базе LSDB, что окажет влияние на работоспособность маршрутизатора или процесса маршрутизации. Это, конечно, маловероятно и т.д, но мне представляется неправильным, когда сторона, которой следует доверять ограниченно, слишком глубоко интегрируется в инфраструктуру. Поэтому полагаю, что поднятие OSPF с клиентами - не самая лучшая идея. Хотя никому ничего не навязываю.
Вот здесь некоторое объяснение разницы: www.tlu.ee/~matsak/telecom/cabling/eu_generic_cabl...по вашей ссылке:
Gigabit Ethernet 1000Base-T specified in the standard IEEE 802.3ab uses transmission technique, in which the transmitted 1000 Mbit/s data signal is splitted into four sub-signals. The data transmission rate of each sub-signal is 250 Mbit/s. These four 250 Mbit/s signals are transmitted over the four pairs of the cable and at the receiver end they are combined again to form 1000 Mbit/ signal. Transmission mode is full duplex, which means that bi-directional and simultaneous 250 Mbit/s transmission is used on each pair.
Дело в том, что стандарт ТX даёт гигабит в каждом направлении по одному линку, когда T подразумевает гигабит в сумме входящего/исходящего направлений.Вот этот момент проясните, будьте добры. Исходя из чего вы делаете такой вывод?
Со все портов метрики снимать на вряд ли получиться, у нас 1200 портов. Дисковая подсистема не потянет.Не понял этого тезиса. Если у вас не хватает объема диска - храните подробную статистику в течение дней-недель и затем агрегируйте. Если не хватает производительности дисковой подсистемы - сохраняйте данные в оперативную память и в фоне записывайте на диск или воспользуйтесь специализированными (time-series data bases) базами данных.