Перейти к содержимому
Калькуляторы

NAT+VFR+BGP на одном маршрутизаторе ?

@SUrov_IBM , Ваша идея заработала! За семЪ весьма Вам благодарен!

 

Но, решив один вопрос - появился следующий. Высокий отклик до любых ресурсов (даже в локальной сети).

 

#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 201/379/552 ms

 

#ping 1XX.6X.2X.18   (до вышестоящего шлюза)

Sending 5, 100-byte ICMP Echos to  1XX.6X.2X.18, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 236/484/1292 ms

 

 

Консоль у циски порой тормозит/фризит - тут либо проц, либо оператива в полку. Вообщем выясняю.

 

Update, спустя пару минут:

Да, не вывозит циска через туннель гнать трафик:

 8777777777733333                                             
     299999333334444444444444444444455555444446666644444777776666
 100                                                              
  90                                                              
  80 ******                                                       
  70 ***********                                                  
  60 ***********                                                  
  50 ***********                                                  
  40 ***********                                                  
  30 ****************                                             
  20 ****************                                             
  10 ****************               *****     *****     *********
    0....5....1....1....2....2....3....3....4....4....5....5....6
              0    5    0    5    0    5    0    5    0    5    0
              CPU% per second (last 60 seconds)

 


это при одном запросе до 8.8.8.8

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 07.12.2021 в 18:15, RN3DCX сказал:

Да, не вывозит циска через туннель

RN3DCX,

 

Честно говоря, странно. Я мог предположить, что NAT будет сильно нагружать CPU на CISCO 2811, но не трафик маршрутизируемый просто через туннель. Или у Вас такая картина появляется при использовании NAT?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да, как только накинул NAT на туннель маршрутизатор сразу начал притормаживать.

Убираю NAT c interface Tunnel101 и отклик сразу нормализуется:

R1_Primary#ping 8.8.8.8      
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 15/15/15 ms

 

В целом согласен, странно это как-то...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 07.12.2021 в 18:33, RN3DCX сказал:

В целом согласен, странно это как-то...

Да нет, для CISCO 2811 не странно к сожалению, она под NAT очень сильно проседает по CPU. И не важно, на туннельном он интерфейсе или физическом. Ещё в 2010 году столкнулся с тем, что больше 30 Мб/Сек через NAT она не "прожёвывает". Тогда пришлось ограничить скорость получателя (ip nat inside) до 10 Мб/Сек и помнится ей полегчало.

 

На моё удивление, CISCO 881 не плохо справляется с NAT, это если из "маленьких" смотреть.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Подскажите, у Вас из GRT траффик с MTU 1500 в Интернет нормально проходит?
#ping 8.8.8.8 source 149.126.96.1 size 1500 df-bit

 

И посмотрите пожалуйста, не растёт ли значение fragment:
#sh ip traf | i fragmented
0 fragmented, 0 fragments, 5 couldn't fragment
 

Изменено пользователем SUrov_IBM

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 07.12.2021 в 20:47, SUrov_IBM сказал:

Да нет, для CISCO 2811 не странно к сожалению, она под NAT очень сильно проседает по CPU. И не важно, на туннельном он интерфейсе или физическом. Ещё в 2010 году столкнулся с тем, что больше 30 Мб/Сек через NAT она не "прожёвывает". Тогда пришлось ограничить скорость получателя (ip nat inside) до 10 Мб/Сек и помнится ей полегчало.

 

На моё удивление, CISCO 881 не плохо справляется с NAT, это если из "маленьких" смотреть.

Более толстая 7206 с нпег2 не пережевывает с нат, уделывается по cpu при меньшем трафике. При 400 pptp и nat уже ложится, правда это были скубенты в общаге...

 

В 07.12.2021 в 21:01, SUrov_IBM сказал:

Подскажите, у Вас из GRT траффик с MTU 1500 в Интернет нормально проходит?
#ping 8.8.8.8 source 149.126.96.1 size 1500 df-bit

 Чего хакеров поощряете, пингая с чужого сорса ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 07.12.2021 в 19:04, YuryD сказал:

Чего хакеров поощряете, пингая с чужого сорса ?

YuryD,

 

Просто, форумчанин RN3DCX для конспирации от фонаря указал именно этот IP адрес и он фигурирует в конфигурационных примерах в теме, чтобы было удобнее понять друг друга. Если это Ваш IP, то извиняйте нас пожалуйста. ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 07.12.2021 в 21:15, SUrov_IBM сказал:

YuryD,

 

Просто, форумчанин RN3DCX для конспирации от фонаря указал именно этот IP адрес и он фигурирует в конфигурационных примерах в теме, чтобы было удобнее понять друг друга. Если это Ваш IP, то извиняйте нас пожалуйста. ;)

 Никогда, просто копипастеры это возьмут за пример :) Реально при эксплуатации софтроутеров от киско, понял - они железные как верблюды и ишаки, груз примут, но понесут неспешно...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 07.12.2021 в 19:23, YuryD сказал:

просто копипастеры это возьмут за пример :)

Там же source. ;) Если кто-то и возьмёт за пример настройку с форума, он же должен понимать, что IP source в его случае должен быть другим, иначе у него будет % Invalid source address- IP address not on any of our up interfaces. Хотя Вы правы, некоторые мамины хакеры, умудряются брать конфигурацию совершенно бездумно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 Вы так верите в современных одминов ?  Они умеют копипаст, этого им хватает.... Я пока не нашел ни одного у себя на замену мне, их зряплата не устраивает, и возможности реально порулить, а меня не их желание порулить, а отсутствие знаний, ищут в ответах майлвру...

 

 И да, у нас разрешено логиниться хз с каких левых ресурсов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 07.12.2021 в 19:50, YuryD сказал:

Вы так верите в современных одминов ?  Они умеют копипаст, этого им хватает.... Я пока не нашел ни одного у себя на замену мне, их зряплата не устраивает, и возможности реально порулить, а меня не их желание порулить, а отсутствие знаний

I Want to Believe. ;) На самом деле, есть те, кто действительно хочет разбираться в сетевых технологиях на уровне протоколов, а не просто хвататься за приложение со словами -  "Ну там IP’ник прописать...". Людей с логическим мышлением среди нас достаточно много, просто не сразу удаётся их узнать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 07.12.2021 в 19:50, YuryD сказал:

Вы так верите в современных одминов ?  Они умеют копипаст, этого им хватает....

Как аФтор темы говорю - пусть копируют! на первом же выше стоящем маршрутизаторе эта подсеть закончит свою жизнь...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ради теста, быстренько собрал стенд c CISCO 2811 и произвёл замер скорости. На CISCO только NAT, ничего лишнего. В результате, получилась вот такая картинка:

 

Показания Speedtest от Ookla:

Снимок.JPG

 

Собственно, что в этот момент происходит с CPU CISCO 2811 (при этом консоль «висит практически наглухо»):

Снимок1.JPG

 

А вот, просто ICMP большими пакетами с VM под WINDOWS, где был запущен Speedtest :

Снимок2.JPG

Изменено пользователем SUrov_IBM

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 07.12.2021 в 19:01, SUrov_IBM сказал:

И посмотрите пожалуйста, не растёт ли значение fragment:
#sh ip traf | i fragmented
0 fragmented, 0 fragments, 5 couldn't fragment

RN3DCX,


NAT на CISCO 2811 конечно оставляет желать лучшего, но такие резкие "скачки" в задержках, это обычно фрагментация пакетов на интерфейсах, которая собственно и "уничтожает" CPU. Добавьте в конфигурацию следующие строки:

 

interface Loopback101
 description Loopback-source-GLOBAL
 ip address 100.255.255.1 255.255.255.255
 ip mtu 1520
!
interface Loopback202
 description Loopback-source-VRF-GW-ASXXXXX
 ip address 100.255.255.2 255.255.255.255
 ip mtu 1520
!
interface Tunnel101
 description GLOBAL-to-VRF-GW-ASXXXXX
 ip address xxx.xxx.xxx.xxx 255.255.255.252
 ip nat outside
 ip virtual-reassembly in
 tunnel source Loopback101
 tunnel mode ipip
 tunnel destination 100.255.255.2
!
interface Tunnel202
 description VRF-GW-ASXXXXX-to-GLOBAL
 ip vrf forwarding Inet
 ip address xxx.xxx.xxx.xxx 255.255.255.252
 tunnel source Loopback202
 tunnel mode ipip
 tunnel destination 100.255.255.1
 

 

Погасите интерфейсы Tunnel101, Tunnel202 и заново разрешите (shutdown, no shutdown в interface).

 

Проверьте Tunnel transport MTU на интерфейсах Tunnel101 и Tunnel202, оно должно быть 1500:

 

#sh interface Tunnel101 | i MTU
  Tunnel transport MTU 1500 bytes

 

#sh interface Tunnel202 | i MTU
  Tunnel transport MTU 1500 bytes

 

После обнулите счетчик:
#clear ip traf

Фрагментация не должна возрастать:
#sh ip traf | i fragmented
0 fragmented, 0 fragments, 0 couldn't fragment

 

 

Если фрагментация не будет возрастать, это должно уменьшить задержки. Правда NAT, скорей всего, всё равно не будет обеспечивать нормальной по нынешним меркам скорости (нужно проверять). Но без фрагментации пакетов, CISCO хотя бы не так сильно будет коллапсировать. Попробую в ближайшее время протестировать подобную конфигурацию на CISCO 881 (к сожалению, сейчас нет под рукой), там вроде полегче с этим должно быть.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

SUrov_IBM, Благодарствую в очередной раз!

Чуть позже попробую предложенный вами вариант.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 08.12.2021 в 03:48, SUrov_IBM сказал:

Попробую в ближайшее время протестировать подобную конфигурацию на CISCO 881

RN3DCX,

 

Как и обещал, попробовал протестировать NAT на Tunnel интерфейсе CISCO C881-K9 (не путайте с CISCO 881 (MPC8300)). Результат оказался разительно лучше, чем у CISCO 2811.

 

Конфигурация:

 

interface Loopback10
 description Loopback-source-GLOBAL
 ip address 10.255.255.1 255.255.255.255
 ip mtu 1520
!
interface Loopback20
 description Loopback-source-VRF-GW-ASXXXXX
 ip address 10.255.255.3 255.255.255.255
 ip mtu 1520
!
interface Tunnel101
 description GLOBAL-to-VRF-GW-ASXXXXX
 ip address 193.xxx.xxx.34 255.255.255.252
 ip nat outside
 ip virtual-reassembly in
 tunnel source Loopback10
 tunnel mode ipip
 tunnel destination 10.255.255.3
!
interface Tunnel202
 description VRF-GW-ASXXXXX-to-GLOBAL
 ip vrf forwarding VRF-GW-ASXXXXX
 ip address 193.xxx.xxx.33 255.255.255.252
 tunnel source Loopback20
 tunnel mode ipip
 tunnel destination 10.255.255.1

 

 

ip access-list extended NAT-C881-K9
permit ip 172.0.255.0 0.0.0.7 any
!
ip nat inside source list NAT-C881-K9 interface Tunnel101 overload
!
interface Vlan4091
 ip address 172.0.255.6 255.255.255.248
 ip nat inside
 ip virtual-reassembly in

 

 

Проверяем Tunnel transport MTU:

 

#sh interface Tunnel101 | i MTU
  MTU 17920 bytes, BW 100 Kbit/sec, DLY 50000 usec,
  Tunnel transport MTU 1500 bytes

 

#sh interface Tunnel202 | i MTU
  MTU 17920 bytes, BW 100 Kbit/sec, DLY 50000 usec,
  Tunnel transport MTU 1500 bytes

 

Загрузка CPU, в момент тестирования скорости:

 

#sh processes cpu history

  100
   90
   80
   70
   60  **********
   50  **********
   40  ***************     **********
   30  ******************************
   20 *******************************
   10 **********************************************
     0....5....1....1....2....2....3....3....4....4....5....5....6
               0    5    0    5    0    5    0    5    0    5    0
               CPU% per second (last 60 seconds)

 

 

Отсутствие фрагментации на Tunnel transport:

#sh ip traf | i fragmented
  0 fragmented, 0 fragments, 0 couldn't fragment

 

 

Общие сведения о платформе:

 

#show inventory
NAME: "C881-K9", DESCR: "C881-K9 chassis, Hw Serial#: FCZ190690PA, Hw Revision: 1.0"
PID: C881-K9           , VID: V01, SN: FCZ190690PA
NAME: "C881 Mother board on Slot 0", DESCR: "C881 Mother board"
PID: C881-K9           , VID: V01, SN: FOC18484KT5

 

#sh ver
Cisco IOS Software, C800 Software (C800-UNIVERSALK9-M), Version 15.4(3)M4, RELEASE SOFTWARE (fc1)
ROM: System Bootstrap, Version 15.4(1r)T1, RELEASE SOFTWARE (fc1)
System image file is "flash:c800-universalk9-mz.SPA.154-3.M4.bin"

Cisco C881-K9 (revision 1.0) with 472064K/52224K bytes of memory.
Processor board ID FCZ190690PA
5 FastEthernet interfaces
1 Virtual Private Network (VPN) Module
DRAM configuration is 32 bits wide
255K bytes of non-volatile configuration memory.
250880K bytes of ATA System CompactFlash (Read/Write)


К сожалению, скорость входящего соединения с Интернет на моём канале от вышестоящего узла, не превышает 40 Мб/Сек, поэтому результат не полный, но это намного лучше чем 4 Мб/Сек у CISCO 2811, если мне не изменяет память, то C881-K9 может и больше 60 Мб/Сек «прожевать».

 

Тестирование Speedtest от Ookla:
 

Снимок.JPG

Изменено пользователем SUrov_IBM

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.