Включение NAT на Cisco Nexus 9200

При включении NAT на Cisco Nexus 9200 выяснилось, что ему нужно выделять TCAM и т.к. эта фича не является дефолтовой, то и TCAM свободного под неё нет. Поэтому надо перераспределить имеющийся TCAM - где-то уменьшить, а в NAT добавить.


config# feature nat

Дальше смотрим наличие TCAM под NAT - ему по умолчанию выделено  0

# sh hardware access-list tcam region
                                    NAT ACL[nat] size =    0 (по умолчанию здесь 0 - NAT не работает)
                        Ingress PACL [ing-ifacl] size =    0
                                     VACL [vacl] size =    0
                         Ingress RACL [ing-racl] size = 2304 (здесь много, но занято не всё, см. show hardware access-list resource utilization )
                       Ingress RBACL [ing-rbacl] size =    0
                     Ingress L2 QOS [ing-l2-qos] size =  256
           Ingress L3/VLAN QOS [ing-l3-vlan-qos] size =  512
                           Ingress SUP [ing-sup] size =  512
     Ingress L2 SPAN filter [ing-l2-span-filter] size =  256
     Ingress L3 SPAN filter [ing-l3-span-filter] size =  256
                       Ingress FSTAT [ing-fstat] size =    0
                                     span [span] size =  512
                          Egress RACL [egr-racl] size = 1792
                            Egress SUP [egr-sup] size =  256
                 Ingress Redirect [ing-redirect] size =    0
                      Egress L2 QOS [egr-l2-qos] size =    0
            Egress L3/VLAN QOS [egr-l3-vlan-qos] size =    0
         Ingress Netflow/Analytics [ing-netflow] size =  512
                           Ingress NBM [ing-nbm] size =    0
                            TCP NAT ACL[tcp-nat] size =    0
              Egress sup control plane[egr-copp] size =    0
       Ingress Flow Redirect [ing-flow-redirect] size =    0
               Ingress RACL Lite [ing-racl-lite] size =    0
    Ingress PACL IPv4 Lite [ing-ifacl-ipv4-lite] size =    0
    Ingress PACL IPv6 Lite [ing-ifacl-ipv6-lite] size =    0


Узнаем сколько занято в TCAM:

#show hardware access-list resource utilization
Ingress RACL                            6       2298    0.26 !(занято 0,26% от всех 2304, берем немного отсюда: 512, новое значение будет 1792 )

Урезаем  (указываем новый, уменьшенный размер) TACM у Ingress RACL на 512 (2304-512=1792)

#conf t
config#hardware access-list tcam region ing-racl 1792

Выделяем высвобожденные ранее 512 на NAT:
config#hardware access-list tcam region nat 512
(Для применения требуется перезагрузка)

Контролируем выделенный TCAM на NAT:

#sh hardware access-list tcam region
                                    NAT ACL[nat] size =  512 (512 появилось здесь)
                        Ingress PACL [ing-ifacl] size =    0
                                     VACL [vacl] size =    0
                         Ingress RACL [ing-racl] size = 1792 (512 забралось отсюда)
                       Ingress RBACL [ing-rbacl] size =    0
                     Ingress L2 QOS [ing-l2-qos] size =  256
           Ingress L3/VLAN QOS [ing-l3-vlan-qos] size =  512
                           Ingress SUP [ing-sup] size =  512
     Ingress L2 SPAN filter [ing-l2-span-filter] size =  256
     Ingress L3 SPAN filter [ing-l3-span-filter] size =  256
                       Ingress FSTAT [ing-fstat] size =    0
                                     span [span] size =  512
                          Egress RACL [egr-racl] size = 1792
                            Egress SUP [egr-sup] size =  256
                 Ingress Redirect [ing-redirect] size =    0
                      Egress L2 QOS [egr-l2-qos] size =    0
            Egress L3/VLAN QOS [egr-l3-vlan-qos] size =    0
         Ingress Netflow/Analytics [ing-netflow] size =  512
                           Ingress NBM [ing-nbm] size =    0
                            TCP NAT ACL[tcp-nat] size =    0
              Egress sup control plane[egr-copp] size =    0
       Ingress Flow Redirect [ing-flow-redirect] size =    0
               Ingress RACL Lite [ing-racl-lite] size =    0
    Ingress PACL IPv4 Lite [ing-ifacl-ipv4-lite] size =    0
    Ingress PACL IPv6 Lite [ing-ifacl-ipv6-lite] size =    0

NAT настраивается как обычно, но есть ограничение:
в VPC-моде  PBR отбирает трафик у NAT и натирования не происходит, поэтому надо обходиться только статическими маршрутами. Т.е. если есть несколько UP-линков, то PBR на локальном интерфейсе не позволит натировать входящий из локального сегмента трафик (обратный и\или прямой).

Троблешутинг Cisco ASA

При очередном обновлении Cisco ASA возникла неприятная ситуация, когда трафик почему-то пошел не в свои интерфейсы, на которые были статические маршруты, естественно возник асимметричный трафик  и он стал отбрасываться. Изначально переход был с релиза 8.4(1) на 9.0(3) и затем на 9.8(4)-15. при переходе с 8.4(1)  конфигурация была автоматически адаптирована промежуточным релизом 9.0(3) и на нем работала предсказуемо. При обновлении secondary ноды c 9.0(3) до 9.8(4)-15 проблем не было, и когда роль активной передали на secondary ноду, тоже всё работало нормально штатно, но когда обновили master ноду c 9.0(3) до 9.8(4)-15 и сделали активной, то трафик перестал ходить согласно таблицы маршрутизации, что привело к тому, что почти весь трафик стал дропаться. Выглядит это примерно так:

дело оказалось, что в каком-то релизе между 9.0(3) и 9.8(4)-15  Cisco поменяла логику определения выходного интерфейса при использовании  NAT и правило вида "nat(any, outside)...." стало отправлять трафик на OUTSIDE интерфейс, не зависимо от таблицы маршрутизации, т.е. route-lookup для NAT раньше был по умолчанию для правил NAT (хотя его можно было и указать явно в конфигурации). При указании этой опции на 9.8(4)-15 трафик пошел согласно таблицы статической маршрутизации.
Для отладки Cisco ASA можно использовать следующие команды:

создадим буфер для захвата трафика между определёнными IP:

cap capin trace interface management match ip host 10.0.19.49 host 10.129.190.3

cap capout trace interface DMZ-18 match ip host 10.129.190.3 host 10.0.19.49

cap asp type asp-drop all

Смотрим капчи:
ciscoasa/admin# show cap
capture capin type raw-data interface management [Capturing - 2250 bytes]
  match icmp host 10.0.19.49 host 10.129.190.3
capture capout type raw-data interface DMZ-18 [Capturing - 2820 bytes]
  match icmp host 10.0.19.49 host 10.129.190.3
capture asp type asp-drop all [Capturing - 534 bytes]
ciscoasa/admin# show cap asp

6 packets captured

   1: 14:46:01.645535       802.3 encap packet Drop-reason: (l2_acl) FP L2 rule drop

   2: 14:46:03.645535       802.3 encap packet Drop-reason: (l2_acl) FP L2 rule drop

   3: 14:46:03.765997       802.1Q vlan#58 P7 10.129.190.4.5353 > 224.0.0.251.5353:  udp 320 Drop-reason: (acl-drop) Flow is denied by configured rule

   4: 14:46:04.895354       0.0.0.0.68 > 255.255.255.255.67:  udp 292 Drop-reason: (acl-drop) Flow is denied by configured rule

   5: 14:46:05.645504       802.3 encap packet Drop-reason: (l2_acl) FP L2 rule drop

   6: 14:46:07.645489       802.3 encap packet Drop-reason: (l2_acl) FP L2 rule drop


ciscoasa/admin# show cap capout

8 packets captured

   1: 14:46:46.298431       802.1Q vlan#58 P0 10.0.19.49 > 10.129.190.3 icmp: echo request
   2: 14:46:46.298980       802.1Q vlan#58 P0 10.129.190.3 > 10.0.19.49 icmp: echo reply
   3: 14:46:51.298904       802.1Q vlan#58 P0 10.0.19.49 > 10.129.190.3 icmp: echo request
   4: 14:46:51.299545       802.1Q vlan#58 P0 10.129.190.3 > 10.0.19.49 icmp: echo reply
   5: 14:46:56.302352       802.1Q vlan#58 P0 10.0.19.49 > 10.129.190.3 icmp: echo request
   6: 14:46:56.303008       802.1Q vlan#58 P0 10.129.190.3 > 10.0.19.49 icmp: echo reply
   7: 14:47:01.301757       802.1Q vlan#58 P0 10.0.19.49 > 10.129.190.3 icmp: echo request
   8: 14:47:01.302398       802.1Q vlan#58 P0 10.129.190.3 > 10.0.19.49 icmp: echo reply
8 packets shown


ciscoasa/admin# show cap capout trace packet-number 2

12 packets captured

   2: 14:46:46.298980       802.1Q vlan#58 P0 10.129.190.3 > 10.0.19.49 icmp: echo reply
Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 3
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (any,outside) source static ASA-DMZ-pool ASA-DMZ-pool destination static INTERNAL_without-1-77-78 INTERNAL_without-1-77-78
Additional Information:
NAT divert to egress interface outside
Untranslate 10.0.19.49/1 to 10.0.19.49/1

Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group global_access global
access-list global_access extended permit icmp any4 any4 log warnings
Additional Information:

Phase: 5
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (any,outside) source static ASA-DMZ-pool ASA-DMZ-pool destination static INTERNAL_without-1-77-78 INTERNAL_without-1-77-78
Additional Information:
Static translate 10.129.190.3/0 to 10.129.190.3/0

Phase: 6
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:

Phase: 9
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (any,outside) source static ASA-DMZ-pool ASA-DMZ-pool destination static INTERNAL_without-1-77-78 INTERNAL_without-1-77-78
Additional Information:

Phase: 10
Type: USER-STATISTICS
Subtype: user-statistics
Result: ALLOW
Config:
Additional Information:

Phase: 11
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 34202383, packet dispatched to next module

Phase: 12
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (any,outside) source static ASA-DMZ-pool ASA-DMZ-pool destination static INTERNAL_without-1-77-78 INTERNAL_without-1-77-78
Additional Information:
NAT divert to egress interface outside
Untranslate 10.0.19.49/1 to 10.0.19.49/1

Phase: 13
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group global_access global
access-list global_access extended permit icmp any4 any4 log warnings
Additional Information:

Phase: 14
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (any,outside) source static ASA-DMZ-pool ASA-DMZ-pool destination static INTERNAL_without-1-77-78 INTERNAL_without-1-77-78
Additional Information:
Static translate 10.129.190.3/0 to 10.129.190.3/0

Phase: 15
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 16
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 17
Type: SUBOPTIMAL-LOOKUP
Subtype: suboptimal next-hop
Result: ALLOW
Config:
Additional Information:
ifc selected is not same as preferred ifc
Doing route lookup again on ifc  outside

Phase: 18
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 10.0.1.32 using egress ifc  outside

Result:
input-interface: DMZ-18
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

1 packet shown

На релизе 9.0(3) trace  выглядит так:

ciscoasa/admin# cap capin trace interface management match ip host 10.0.19.49  host 10.129.128.4
ciscoasa/admin# show capture capin

4 packets captured

   1: 10:27:40.850786       10.0.19.49 > 10.129.128.4: icmp: echo request
   2: 10:27:40.851274       10.129.128.4 > 10.0.19.49: icmp: echo reply
   3: 10:27:41.866150       10.0.19.49 > 10.129.128.4: icmp: echo request
   4: 10:27:41.866623       10.129.128.4 > 10.0.19.49: icmp: echo reply
4 packets shown
ciscoasa/admin# show capture capin trace packet-number 1

26 packets captured

   1: 10:27:40.850786       10.0.19.49 > 10.129.128.4: icmp: echo request
Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 3
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found flow with id 1846, using existing flow

Result:
Action: allow


1 packet shown

Ссылка на Cisco:
https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/118097-configure-asa-00.html

Настройка ограничений неприятного трафика для c6500 (sup720).

Сложилась ситуация, когда в ИТ-инфраструктуре произошла смена поколений серверов, но остались старые ядра сети, которые в свое время были флагманами. Петли генерируемые при неправильной настройки виртуальных свичей раньше не приносили больших проблем ядру - запас производительности позволял спокойно разбираться с нарушителями. Но сейчас, когда любой сервер обладает огромной мощностью и очень производительными сетевыми картами, картина изменилась - петли стали загружать CPU sup720 (cisco 6500) на 100% и страдать начинают все, при этом множественный мониторинг по SNMP, ICMP тоже повышает утилизацию, что усугубляет ситуацию.

Как меру по разгрузки ядра (уже) надо включать некое ограничение нагрузки на CPU самого ядра сети от внешних запросов.

на sup720 есть некоторые ограничения по применению механизма control-plane  (COPP)  - он не может работать с L2, т.е. ему нельзя в policy указывать L2 связанные параметры: mac, arp.
политику можно применить только если есть L3 описание трафика в class-map, а также минимальное ограничение в 32000 bit/s.

пример:
!
ip access-list extended icmp-to-core
 permit icmp any host <core ip>

ip access-list extended snmp-core
 permit udp any host <core ip> eq snmp

class-map match-all copp-icmp
  match access-group name icmp-to-core

class-map match-all copp-snmp
  match access-group name snmp-core

policy-map copp
  class copp-icmp
   police 32000 1500 1500    conform-action transmit     exceed-action drop
class copp-snmp
   police 64000 3200    conform-action transmit     exceed-action drop

control-plane
 service-policy input copp

(желательно, при добавлении в policy-map нового class-map, выключать service-policy из  control-plane, добавлять class в policy-map и затем опять включать в control-plane, т.к. производится проверка совместимости policy и control-plane, в противном случаем можно добавить в policy-map не совместимы параметр, что может привести к крешу IOS)


L2 ограничения можно установить только через mls qos:
!
mls qos
mls cef error action reset
mls qos map policed-dscp normal-burst 0 24 26 34 36 to 8
mls qos map cos-dscp 0 10 18 24 34 46 48 56
mls qos protocol ARP police 640000 6400 


И надо рассматривать включение storm-control на всех интерфейсах, т.к. риск отключить отдельный сегмент сети уже не так страшен, по сравнению с неработоспособность всей сети.

Простая обработка простого вывода: grep, awk, sort.

Иногда нужно понять что и как работает на множестве устройств, но заходить для этого на каждое устройства нет смысла если есть общее место хранения файлов конфигурации и последняя конфигурация сохраняется в этом месте автоматически. Для поиска нужной строки можно запустить поиск по содержимому в каталоге с файлами сохраненных конфигураций.
Т.к.  сохраняются файлы и предыдущих версий конфигурации, то  более новые помечаются добавлением номера версии "-ХХ" и если просто запустить grep <pattern>, то будет множество строк с одинаковыми названиями устройств, отличающихся только последними 2-3 знаками. Задача: найти файлы, отрезать индексы номера версий в названии, и выдать по одной уникальной строке на одно устройство. Решение примерно такое:
1) ищем подходящий паттерн (grep), подаём его на вход (awk), где указываем разделитель полей ((-F ":"), если нет то "пробел"), указываем в awk  чтобы вывел первую (или другую) Часть (относительно разделителя), но изменённую  substr, аргументом которой будет:
часть строки ($1),  далее номер  символа  для начала вывода в этой Части, и номер последнего символа в Части, длину которой определяем динамически оператором  length($1) и от которой отрезаем номер версии файла конфигурации 4  символа (надо подбирать, т.к. это д.б. с учетом сдвинутого ранее на 2 вывода Части). После этого подадим на вход команде sort -u для исключения одинаковых названий (без номера версий названия всех файлов конфигурации для одного узла будут одинаковы, и будет много одинаковых строк).

grep  "^interface Vlan5" ./* | awk -F ":" '{print substr($1,3,length($1)-4)}' | sort -u > vl5

Этот приём можно использовать когда название файла конфигурации можно ассоциировать с определённым узлом и тогда будет выведен столбец с названиями узлов, где имеется требуемая строка в конфигурации.

после grep:
./zld-lnn32-do-0:interface Vlan5
./zld-lnn32-do-1:interface Vlan5
./zld-lnn32-do-2:interface Vlan5

после  awk:
zld-lnn32-do
zld-lnn32-do
zld-lnn32-do

после sort:
zld-lnn32-do

Pfsence оптимизация VPN и mapping с подменой src и dst IP адресов.

Накопилось куча VPN подключений, попросили сделать ещё 2.
Решил их сделать на собранном ранее кластере pfsence, смотрящим в BGP AS, с 2-я аплинками.
Главная цель - полная горячая отказоустойчивость, реализованная на всех компонентах инфраструктуры, как связи так и виртуализации.
Вторая цель это возможность проверки соединений  к самим  сервисам внутри ВПН, т.к. при обычном построении IPSEC фазы 2 всегда указываются IP конечных хостов (сетей) к которым у меня нет доступа, чтобы  прямо с них проверить.
Третья цель это не мусорить маршрутизацию внутри своей локальной сети, адресами контрагентов, и решить возможные проблемы при их совпадении.
Для решения этих проблем выделил виртуальный IP адрес на pfsence, который разделяется между нодами (CARP)  pfsence и указал его в качестве нашего внутреннего для фазы 2 (для контрагентов). На этот же  виртуальный IP повесил port-forwarding с произвольными (но систематизированными) TCP портами, начиная с 5000, последовательно примапливая каждый следующий порт к необходимому TCP сервису внутри VPN:
Pfsence-virt-IP:5000->insideVPN-IP:80
Pfsence-virt-IP:5001->insideVPN-IP:443
и т.д.

Таким образом для клиента с нашей стороны полностью подменивается и dst:port , а для сервера на стороне контрагента  подменивается src (и port) и все запросы приходят с Pfsence-virt-IP.

Обычно это делается  прописыванием 2-х правил в секции NAT: port-forward и outbound ,
сначала (NAT->port-forward) начинаем слушать на нужном порту, подменяем dst:port и посылаем внутрь pfsence, затем на выходном интерфейсе (NAT->outbound) подмениваем src.
всё это прекрасно работает для статических интерфейсов. Но с IPSEC трафиком это не проходит, хотя  в настройках NAT->outbound есть интерфейс IPSEC, всё равно всё шлётся согласно существующей статической маршрутизации, т.е. не уходит в интерфейс IPSEC (pfsence не понимает что есть connected "insideVPN-IP" через IPSEC) и NAT-outbound не работает, и действительно, в какой из множества живых IPSEC его посылать?.
Как оказалось это связано с особенностями обработок цепочек фаервола при IPSEC.
Решается это применением NAT/BINAT в самой настройкt фазы 2 IPSEC подключения.

Далее приведу 2 примера полного Порт-IP маппинга для обычных интерфейсов и для IPSEC.

1) Между обычными интерфейсами:

Внутренний хост  10.143.8.26 цель которого попасть на 10.0.1.186:80, у  10.143.8.26 нет возможности быть смаршрутизированным на 10.0.1.186, но есть возможность достигнуть 10.129.170.130 (виртуальный IP pfsence) на  интерфейсе ОРТ2.
Pfsence не является шлюзом и пропускает простой транзитный трафик.
10.0.1.128 это IP LAN интерфейса pfsence, хост 10.0.1.186  не имеет маршрутной информации о 10.143.8.26, но достижим с 10.0.1.128. Выберем порт 9191, который будет слушать на 10.129.170.130.
Для этого прописываем в разделе:

принимаем подключение с определенного IP  10.143.8.26 (указываем в advanced option), иначе будет создано (автоматически в разделе Rules/OPT2) правило которое разрешит ВСЕМ доступ к данному форвардингу: 10.129.170.130:9191
Обязательно пишем дескрипшен, чтобы потом найти созданное автоматом правило в Rules, оно будет таким: "NAT <desc...>"

Затем создаем ещё одну трансляцию, но уже outbound:

Здесь указываем, что выходя через LAN (а определяется это статической маршрутизацией), то подменить для совпадающих IP , src на "Interface Address".

2) Маппинг в VPN

Внутренний хост  10.30.0.62 (которому надо через ВПН подключиться (в идеале) к внешнему 192.168.99.1)

Виртуальный IP на pfsence (Pfsence-virt-IP)  10.129.170.130 , он доступен внутренним хостам (и 10.30.0.62) без дополнительной маршрутизации. 10.129.170.130 будет слушать на 5000 порту, 10.129.170.130 также является нашим внутренним IP для VPN (т.е. у него 2 независимых роли, можно использовать и 2 разных IP).

Опускаю процесс поднятия IPSEC Phase 1 - он обычный.
Фазу 2 поднимаем для оговоренных с Той стороной пары IP адресов (сетей)   10.129.170.130 <->  192.168.99.1

Первое:
прописываем Port-Forward (аналогично пункту 1), в котором описываем подмену DST IP(:port) с 10.129.170.130:5000 на 192.168.99.1:80

Второе:
Для IPSEС обычный NAT - Outbound не работает, поэтому будем использовать опцию NAT/Binat в phase2 IPSEC соединения.
Добавляем еще одну запись phase2 (2-ю, 3-ю если понадобится), где указываем  SRC IP из нашей локальной сети, которое надо подменить IP на оговоренный для нас  с контрагентом (10.129.170.130).

IP на другой стороне VPN - 192.168.99.1 (оно знает только о 10.129.170.130).

Проверка скорости внутри локальной сети и увеличение сетевой производительности для windows 7-10

В последнее время участились жалобы на медленную передачу файлов по протоколу SMB в windows. Канал связи этим протоколом (SMB в один поток) и раньше не мог утилизироваться больше 20-30 % доступной скорости, а сейчас стал не более 5-10%. Ни подбор MTU, заведомо проходящий без фрагментации, ни повышение приоритета, ничего не помогает. Поэтому было решено прикрутить сервис альтернативной проверки скорости, не использующий прокол SMB и Проводник. Для это был найден  не очень загруженный Линукс с apache и установлен из github.com один из доступных HTML5 speedtest-еров.
процесс установки:

https://github.com/adolfintel/speedtest


============

смена MTU:


1) получаем список интерфейсов:

netsh interface ipv4 show subinterfaces

2) изменяем MTU:

netsh interface ipv4 set subinterface "Ethernet" mtu=1400 store=persistent



так как это не помогает, то надо тюнить размер окна:



один из путей

netsh interface tcp set global autotuninglevel=disabled

netsh interface tcp set global rss=disabled

netsh interface tcp set global chimney=disabled

netsh interface tcp set global netdma=disabled

и изменить настройки адаптера:

--

полнее здесь: https://www.softjoys.pro/interesting/53

мне не помогло, но может поможет в другой ситуации



этот метод мне частично помог, особенно 1-й пункт (скорость увеличилась в 2 раза, с 5-10% до 10-20% от способности канала):

netsh interface tcp set heuristics wsh=disabled

netsh int tcp set global rss=enabled

netsh interface tcp set global autotuning=experimental

netsh interface tcp set global congestionprovider=ctcp
В заключении, как мне кажется, скорость теперь только функция от задержки,
и при задержках в 100 мс, добиться максимальной скорости по SMB практически невозможно. подробно тут:
https://www.duckware.com/blog/how-windows-is-killing-internet-download-speeds/index.html

для проверки скорости скачивания через WEB можно опубликовать в WEB каталог с файлами, для этого надо добавить в конфигурационный файл apache (он может находиться в разным местах и названиях) секцию и убедиться, что модуль mod_autoindex  включен:



<Directory /usr/local/apache2/htdocs/listme>

  Options +Indexes
</Directory>
для правильного отображением названий файлов на русском языке необходимо добавить в файл .htaccess следующий код:
IndexOptions +Charset=UTF-8

--

Эмуляция port-mapping в cisco

Часто бывает необходимо, при пробросе  извне NAT вовнутрь сети, сменить не только destination, но и source (wan) IP  адреса, чтобы не заморачиваться с наличием маршрута по умолчанию на локальном устройстве куда идет перенаправление (в этом случае достаточно иметь локальную доступность (маршрутизацию) между пограничным роутером и  целевым внутренним  пунктом назначения). В Cisco появилась опция на интерфейсах ip nat enable (в дополнении к ip nat inside,outside), которая позволяет NAT-транслировать поток 2 раза, как по входу, так и по выходу одновременно. Т.е. входящие из WAN пакеты приходят на стандартный ip nat inside source..  (стандартная конструкция на интерфейсах: ip nat outside, inside), при этом подменивается только адрес назначения на локальный, но исх. адрес (wan ip) остается прежним. Затем мы можем включить ещё одну трансляцию, которая, для уже ранее преобразованного  destinaton IP, подменяет и source IP на применяемые во внутреннем интерфейсе. Этого нельзя было достигнуть раньше, т.к. надо было иметь роли inside, outside на обоих интерфейсах одновременно. Сейчас применив команду ip nat enable мы объясняем роутеру, что нам именно это и нужно. Конфиг выглядит примерно так:

interface Vlan1
description WAN
ip address 10.100.105.224 255.255.255.0
 ip nat outside
 ip nat enable
!
interface Vlan3
 description LAN
 ip address 192.168.224.1 255.255.255.0
 ip nat inside
 ip nat enable
!
ip route 10.144.0.0 255.255.0.0 192.168.224.8
!- узлы в сети 10.144.0.0/16 знают только 192.168.224.0/24, ни ничего не знает о 10.100.105.224
!- и других IP  (10.0.1.0/24) за WAN интерфейсом
ip route 10.0.1.0 255.255.255.0 10.100.105.1
!-- нат для приема из WAN соединений на 222 порт и пересылке его во внутрь на 10.144.0.157
!-- 22 порт
ip nat inside source static tcp 10.144.0.157 22 10.100.105.224 222 extendable
!--- подменяем исх. IP с 10.0.1.ХХХ на 192.168.224.1 (Vlan3)
ip nat source list 101 interface Vlan3 overload
!-- указываем что подменяем только для 10.144.0.157  порт 22
access-list 101 permit tcp 10.0.1.0 0.0.0.255 host 10.144.0.157 eq 22

Сети 10.0.1.0/24 и 10.144.0.0/16  не имеют никакой связности, и маршрутной информации друг о друге, маршруты по умолчанию указывают на другие роутеры и т.д. Но в итоге, с узлов сети 10.0.1.0/24 можно подключиться, через примапленный порт 222  (10.100.105.224 ) и уже с другого IP (192.168.224.1) инициировать подключение к 10.144.0.157 22.