[yoksel]

Доброго времени суток. Возник вопрос - что не так?

Стоит кошка 7206 npe g2 с такими задачами:

1) Бгп

2) Впн сервер

3) пропустить через себя более 600 мбит

Проблема: При загрузке канала 400 мбит и 800 впн сессий, загрузка проца 90-100%, соответственно новые сессии отваливаются и канал не прыгает выше 440 мбит.

 

Вопрос - что не так накрутили, и в чем может быть проблема?

[Valaskor]

перегружена она у вас, 600 это вряд ли реально

что касается проблем с подключением при перегрузке, можно поиграться с настройками scheduler allocate и подобным.

но перегрузка и соответственно потери пакетов и прыгающий пинг все равно будет иметь место.

[ghost]

Выкинуть с нее pptp...

[yoksel]

а как тогда быть с авторизацией?

ставить РС с mpd?

[UglyAdmin]

Кстати, лучший вариант.

[jab]

а как тогда быть с авторизацией?

ставить РС с mpd?

И еще один с quagga под bgp. А кошку на помойку.

[Stak]

А кошку на помойку.

Это жестокое обращение с жывотными...

[ghost]

а как тогда быть с авторизацией?

ставить РС с mpd?

1. Замечено, что pppoe ужрякивает меньше ресурса кошки, нежели pptp.

2. как ни крути, а 72-я как "комбайн все в одном девайсе" - не лучший вариант, вам либо менять девайс, либо распределять нагнрузку на другие девайсы.

3. при достижении определенного уровня зрелости фирмы/начальства/персонала приходит понимание, что обьединение в одном устройстве ядра, бордера и аксеса обладает рядом недостатков, масштабируемость - первый из которых...

[No_name]

а как тогда быть с авторизацией?

ставить РС с mpd?

Да

 

И еще один с quagga под bgp. А кошку на помойку.

Тоже вариант

Изменено 22 сентября, 2009 пользователем ma4o

[KD]

можно и я со своим вопросом влезу?

имеем 7206 NPE1 (IOS 12.4(13f)) как "комбайн все в одном девайсе"

раздает инет в небольшом городе

терминация PPPoE (около 150 онлайн, трафик 6 Мбит/с, всего 400)

nat, NF, ACL + жуткий traffic-shape

о последнем подробнее:

основной тариф - 64 кбит/с на пользователя, с rate-limit-ом на такой скорости работать некомфортно потому стоит traffic-shape. Пользователи привыкли от отказаться теперь нереально. На виртуальных интерфейсах шейпить не получилось, потому создал туннель по которому прогоняю трафик.

interface Virtual-Template1
ip vrf forwarding unlim
ip unnumbered Tunnel101
ip access-group user-in in
ip verify unicast reverse-path allow-self-ping
ip flow ingress
ip flow egress
ip nat inside
ip virtual-reassembly
rate-limit input 1024000 16000 16000 conform-action transmit exceed-action drop
ip tcp adjust-mss 1450
no logging event link-status
no peer default ip address
keepalive 5
ppp authentication chap
end

interface Tunnel101
ip vrf forwarding unlim
ip address 192.168.4.2 255.255.255.252
tunnel source Loopback101
tunnel destination 10.10.10.1

interface Tunnel100
ip address 192.168.4.1 255.255.255.252
ip nat inside
no ip virtual-reassembly
traffic-shape group 2001 64000 8192 16777216 1000
traffic-shape group 2002 64000 8192 16777216 1000
traffic-shape group 2003 64000 8192 16777216 1000
...............................................................................
traffic-shape group 2397 64000 8192 16777216 1000
traffic-shape group 2398 64000 8192 16777216 1000
traffic-shape group 2399 64000 8192 16777216 1000
tunnel source Loopback100
tunnel destination 10.10.10.2
end

access-list 2001 permit ip any host 192.168.100.1
access-list 2002 permit ip any host 192.168.100.2
access-list 2003 permit ip any host 192.168.100.3
access-list 2004 permit ip any host 192.168.100.4
access-list 2005 permit ip any host 192.168.100.5
access-list 2006 permit ip any host 192.168.100.6

очень не нравится загрузка цпу

CPU utilization for five seconds: 31%/22%; one minute: 31%; five minutes: 33%
PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
  57     1585548  13030421        121  5.48%  5.67%  5.90%   0 IP Input
175       52064   4928505         10  2.37%  2.39%  2.36%   0 traffic_shape
185       14116       678      20820  0.49%  0.04%  0.00%   0 VTEMPLATE Backgr
170        5560    924854          6  0.16%  0.15%  0.16%   0 PPP Events
  37       26568     19828       1339  0.16%  0.09%  0.10%   0 Net Background
  34        8876    865037         10  0.16%  0.08%  0.14%   2 Virtual Exec
172        4804     91784         52  0.08%  0.10%  0.12%   0 IP NAT Ager
  88        1908     62636         30  0.08%  0.02%  0.00%   0 DHCPD Receive
183       28328    903619         31  0.08%  0.07%  0.08%   0 NAT MIB Helper
167         764    234292          3  0.08%  0.00%  0.00%   0 PPPoE Background
160       10388    983220         10  0.08%  0.08%  0.08%   0 RADIUS
...........

это при 4,5 Мбит и 110 онлайн

до этого стояла 2821 загрузка на ней при той же схеме была около 50-60%

 

вопрос - что можно сделать для уменьшения загрузки? хочется на этой железке терминировать около 300 онлайн (600-700 всего) с трафиком 15-20 мбит/с

может не все рассказал, спрашивайте

[ghost]

увеличить скорости :)

резал rate-limit-ом по 64k прямо на виртуале, более-менее нормально получалось.

2811 - 330 pppoe коннектов 40Мбит трафа - 95% CPU :)

[ghost]

Можно кстати 72к rate-limit-ом чикнуть, и народ будет счастлив, и вы нагрузку с кошки уберете.

Можнол еще ИОС повыбирать, какой-то из веток W... или X.. умел на виртуалах шейпить через сервис-полиси.

[nnm]

Мне кажется, что основная проблема в том, что на интерфейс навешана длииииная гирлянда шейперов. Т.е. пакетик, судьба которого сматчится с access-list 2399 последовательно переберет все access-list. И ему будет тяжело :). Мне кажется, что правильный путь - это вешать police-map на virtual-access, передавая соответствующий атрибут при аутентификации абонента.

[KD]

благодарю за ответы

Мне кажется, что основная проблема в том, что на интерфейс навешана длииииная гирлянда шейперов. Т.е. пакетик, судьба которого сматчится с access-list 2399 последовательно переберет все access-list. И ему будет тяжело :). Мне кажется, что правильный путь - это вешать police-map на virtual-access, передавая соответствующий атрибут при аутентификации абонента.

имхо именно так, из-за длинной гирлянды.

policy-map на Vi-Access не работает в этом иосе. Пробовал SB - работает, но как-то криво + еще некоторые косяки есть

есть еще вариант разбить пользователей по группам, чтобы в один туннель попадало 40-50 абонов

[KD]

попробовал разбить сеть /23 на две /24 и пустить по двум туннелям

соответственно список traffic-shape group стал в 2 раза меньше.

пока разницы в загрузке CPU не видно

[ghost]

Откажись от шейпеа, вешай рейт-лимит прямо на виртуал аксесс атрибутом из радиуса...

[KD]

сложно отказаться

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

я понимаю, что дать чуть больше скорости выйдет много дешевле по стоимости чем железка

но пока работает - хотелось бы оттянуть сей момент

Изменено 23 сентября, 2009 пользователем KD

[ghost]

"Первый испуг прошел, полет проходит нормально..."

Думает падающий с 9-ого этажа, пролетая мимо 4-ого.

 

Ничего не меняя вы и оттягиваете этот самый момент.

[KD]

т.е. про шейп на этой железке можно забыть?

ghost, а можно подробнее про

Можнол еще ИОС повыбирать, какой-то из веток W... или X.. умел на виртуалах шейпить через сервис-полиси.

?

Изменено 23 сентября, 2009 пользователем KD

[ghost]

Знакомый с этим долго боролся, ИОС-ы выбирал, оптимизировал....

Потом забил, и всех с НЕ гарантироваными скоростями перевел на рейт-лимит, а с гарантироваными - vpn подкючениями перестал давать.

[boombastic]

можно и я со своим вопросом влезу?

имеем 7206 NPE1 (IOS 12.4(13f)) как "комбайн все в одном девайсе"

раздает инет в небольшом городе

терминация PPPoE (около 150 онлайн, трафик 6 Мбит/с, всего 400)

nat, NF, ACL + жуткий traffic-shape

Как минимум - включите в конце-концов Turbo ACL + Turbo QoS !!!

conf t

access-list compiled

 

 

[KD]

Как минимум - включите в конце-концов Turbo ACL + Turbo QoS !!!

conf t

access-list compiled

включил

разницы не заметил