throughtheether

Спасибо за схему.

Все интерфейсы в полнодуплексном режиме.

Это хорошо.

у меня 3 свитча выбиваются от всех остальных. У них значения cost (4 - 1Гб, 19 - 100Мб) у остальных (20000 - 1Гб, 200000 - 100 Мб). Значения стоят правильно (в схеме указал в одной системы дабы проще понять было).

Вот здесь не понял. Эти три коммутатора - случайно не sw1,sw2,sw5, о которых дальше говорите? Видимо я непонятно выразился, я считаю, что на всех коммутаторах надо добиться единообразия представления стоимости пути (root path cost). Иначе нам остается гадать, как отображаются друг на друга 16- и 32-битные значения, учитывая, что в BPDU поле имеет длину 32 бита. Чтобы разобраться в этом, потребуется изучение дампа BPDU и прочее. Поэтому прошу повторно привести к единому режиму вычисление стоимости пути. Ключевые слова для поиска в интерфейсе - root path cost short (16-битный вариант), root path cost long (32-битный вариант).

Когда смотрел bridge id заметил странную вещь:
sw1, sw2, sw5 имеют root bridge id точно такой же как и их bridge id. На остальных свитчах все хорошо.

Это плохо. Значит, каждый из них считает себя корневым коммутатором. Возможные причины - непрохождение BPDU. Что еще общего у этих трех коммутаторов? Производитель, может быть?

Установка cost в 300 не помогла. Сеть не перестраивается. Ребут sw9 не является возможным, а ребут sw1 не дает результатов, так же как и ребут sw8.

Я думаю, при правильной работе сети перезагрузка коммутаторов после изменения стоимости линка не потребуется.

priority(128), admin edge(non-edge), point-to-point(forced true) оставлять по умолчанию для всех портов?

Значение priority имеет смысл понижать для корневого коммутатора. Пока предлагаю этого не делать.

Edge port - порт, на котором гарантированно нет петли. Как правило, подключен к рабочей станции или серверу. Соответственно порты, соединяемые линком между коммутаторами не могут быть edge.

Point-to-point - порт, соединенный, как правило, полнодуплексным линком лишь с одним другим портом. Для нормальной работы RSTP все порты должны быть в режиме point-to-point. Если порт переключается в режим shared (например, дуплекс сломался), то RSTP работает, насколько мне известно, в режиме совместимости со 'старым' STP (802.1d).

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

Прошу прощения, прочитал ваш последний вопрос только сейчас. Посмотрите, где именно происходит замедление при помощи водопадной диаграммы (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)