throughtheether

Всегда пожалуйста.

Прошу прощения, прочитал ваш последний вопрос только сейчас. Посмотрите, где именно происходит замедление при помощи водопадной диаграммы (waterfall diagram, в firefox - F12-Сеть). Покажите диаграммы для одного и того же сайта и разных подключений. Пришлите вывод show process cpu sorted с трафиком и без.

Вопрос: как мне сделать так, чтобы разрыв был между "Отдел гл. энергетика" и "правое крыло" ?

Для этого необходимо, на мой взгляд, увеличить значение cost для этого линка с каждой стороны до достаточно высокого значения.

Теперь, что касается этого самого значения. Учитывая гетерогенность вашей сети, стоит убедиться, какие именно значения cost установлены для каждого из интерфейсов, участвующих в RSTP-процессе. Они могут быть как 16-, так и 32-битными, насколько мне известно. Если все значения cost установлены в 4 для гигабитных и 19 для 100-мегабитных портов, должно хватить значения cost 300 для соответствующего линка (с каждой стороны, на случай дальнейшего изменения корневого коммутатора).

Необходимо также убедиться, что каждый из вышеупомянутых интерфейсов работает в полнодуплексном режиме (т.е. является, с точки зрения RSTP, p2p-портом). Это необходимо для корректной обработки изменения топологии (topology change).

Если это не поможет и возникнут дополнительные вопросы, то будьте добры, потрудитесь нарисовать нормальную читаемую схему сети с необходимой информацией (bridge id каждого коммутатора, cost для каждого интерфейса, участвующего в RSTP).

сам не работал, но слышал про такой форк: VyOS

hackaday.com

https://news.ycombinator.com/

Тут уже проблема, как понимаю, в оптимизации работы Apache сервера.

Согласен с вами.

Спасибо за наводки @throughtheether

Рад был помочь.

1) при подключении снаружи время на разрешение имен хостов (DNS resolution) увеличивается до сотен миллисекунд. Если вы планируете доступ снаружи в основном с одного хоста, то можно попробовать прописать на нем DNS, например, 8.8.8.8, и снова построить диаграмму.

2) самое главное - по какой-то причине время на установление tcp-соединения возрастает до тысяч миллисекунд. Здесь можно с клиента проверить пинг до внешнего адреса сервера (т.е. того, который используется при подключении). Если есть линукс-машина с выходом в интернет (или на клиенте стоит линукс), можно воспользоваться hping следующим образом:

hping -c 10 --syn --destport 80 <IP адрес или имя хоста сервера>

Здесь видно, что по какой-то причине (многоуровневый форвардинг, вероятно) DNS-сервер по умолчанию (208.67.222.222), отвечает значительно медленнее DNS Google (8.8.8.8). Попробуйте прописать 8.8.8.8 в качестве DNS сервера - или в настройках операционной системы, или (мне кажется, предпочтительнее) в настройках dhcp-сервера на маршрутизаторе:

ip dhcp pool LAN
   dns-server 8.8.8.8

Попробуйте посмотреть диаграммы загрузки (waterfall diagram, в firefox это F12->Сеть) при открытии страницы из локальной сети и снаружи и сравнить.

Настройка NAT для доступа в локальную сеть и интернет, скорее всего, будет иметь такой вид (можно копипастить отсюда в консоль в режиме configure, сохранив перед этим рабочую конфигурацию):

interface FastEthernet4
 ip nat outside
 exit
no ip nat inside source list INSIDE_NAT interface Dialer0 overload
ip nat inside source route-map INTERNET interface Dialer0 overload
ip nat inside source route-map LOCAL interface FastEthernet4 overload
route-map INTERNET permit 10
 match ip address INSIDE_NAT
 match interface Dialer0
route-map LOCAL permit 10
 match ip address INSIDE_NAT
 match interface FastEthernet4

Проверил в GNS3, такие результаты:

Router#sh ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
icmp 93.190.178.73:18  10.1.1.100:18      8.8.8.8:18         8.8.8.8:18
icmp 192.168.138.152:19 10.1.1.100:19     192.168.117.249:19 192.168.117.249:19

Как это исправить?

Надо смотреть в сторону DNS-серверов. Покажите вывод
time dig ya.ru
и
time dig @8.8.8.8 ya.ru

И после подключения к интернету доступ во внутреннюю сеть невозможен будет?

Скорее всего, возможен, если немного усложнить правила NAT, добавив route-map. Сейчас набросаю.

Для начала, строчку

ip nat inside source route-map map_PPTP interface Dialer0 overload

можно убрать:

no ip nat inside source route-map map_PPTP interface Dialer0 overload

потому как он неактивна, и даже соотвествующий route-map у вас не задан.

Далее, что сейчас происходит - трафик из локальной сети, скорее всего, натируется в адрес, назначенный на FastEthernet4 по dhcp. Поэтому вы имеет доступ к хостам в локальной сети провайдера. Убедиться в этом можно (пришлите ее вывод, пожалуйста) при помощи команды
show ip nat translation
Чего необходимо добиться - чтобы трафик из локальной сети натировался в адрес, назначаемый на интерфейс Dialer0.
Поэтому просьба сохранить текущую 'рабочую' конфигурацию (write mem), повторно дать команду (можно копипастом отсюда в config-режиме)

no ip nat inside source list INSIDE_NAT interface FastEthernet4 overload
no ip nat inside source route-map map_PPTP interface Dialer0 overload
interface FastEthernet4
no ip nat outside
no ip nat enable
exit
ip nat inside source list INSIDE_NAT interface Dialer0 overload
clear ip nat translation

сгенерировать трафик из локальной сети в интернет (проверить доступность интернета) и повторно показать вывод
show ip nat translation

Вернуться назад проще всего будет командой
configure replace nvram:startup-config
или перезагрузив устройство.
Я пока попробую воссоздать ваш кейс в GNS3.

см ниже

Сразу же посмотрел базу External маршрутов OSPF командой show ospf database external - все external маршруты остались без изменений, как редистрибутирование статические, так и с BGP.

вы посмотрели список LSA, а следовало проверить таблицу маршрутизации (show route)

Да, и по поводу временной недоступности - я бы проверил, какие еще изменения пришлись на тот коммит. Если никаких, то это, вероятно, следствие нюансов реализации import-политик (действия по умолчанию).

Я не специалист ни в OSPF, ни в JunOS, но полагаю следующее.
Фильтрация при помощи ключевого слова 'import' производится на не-ASBRах. В LSA-5 нет поля, указывающего, откуда префикс внесен в автономную систему OSPF. Мне трудно сказать, что и как у вас матчилось в вашем policy-statement. Я полагаю, при помощи ключевого слова 'import' имеет смысл фильтровать только по вхождению префикса в какие-либо списки. См. также:

OSPF import policy allows you to prevent external routes from being added to the routing tables of OSPF neighbors. The import policy does not impact the OSPF database.

Вашу задачу (вносить только статические маршруты в виде LSA-5) я бы решал так: на каждом ASBR, который занимается редистрибьюцией внешних префиксов в данную автономную систему OSPF, вот такую политику:

policy-statement static-2-OSPF {
        term 1 {
            from protocol static;
            then accept;
        }
    }

применил бы вот так:

protocols {
    ospf {
        export static-2-OSPF;
        ...
        }
    }

Проверил на Olive, работает.