Jump to content
Калькуляторы

Catalyst 3750G: каков реальный размер таблицы мак-адресов

Всем привет. Помогите разобраться с одним вопросом, который загнал меня в тупик. Имеется свич Cisco Catalyst 3750G. Нужно на мониторинг вывести реальную картину загрузки мак-таблицы и количество свободной в ней памяти.

Всем известно что на каталистах можна использовать разные SDM-профили для реорганизации размера разделов TCAM-памяти под конкретные нужды. На данный момент у меня выбран профиль "desktop routing":

C3750G#show sdm prefer 
The current template is "desktop routing" template.
The selected template optimizes the resources in
the switch to support this level of features for
8 routed interfaces and 1024 VLANs. 

  number of unicast mac addresses:                  3K
  number of IPv4 IGMP groups + multicast routes:    1K
  number of IPv4 unicast routes:                    11K
    number of directly-connected IPv4 hosts:        3K
    number of indirect IPv4 routes:                 8K
  number of IPv4 policy based routing aces:         0.5K
  number of IPv4/MAC qos aces:                      0.5K
  number of IPv4/MAC security aces:                 1K

Ок. Проверяю использование TCAM памяти с помощью следующей команды:

C3750G#show platform tcam utilization 

CAM Utilization for ASIC# 0                      Max            Used
                                             Masks/Values    Masks/values

Unicast mac addresses:                        400/3200        184/1381 
IPv4 IGMP groups + multicast routes:          144/1152          6/26    
IPv4 unicast directly-connected routes:       400/3200        184/1381  
IPv4 unicast indirectly-connected routes:    1040/8320        665/5182  
IPv4 policy based routing aces:               384/512           1/2     
IPv4 qos aces:                                768/768         328/328   
IPv4 security aces:                          1024/1024        591/591   

Note: Allocation of TCAM entries per feature uses
a complex algorithm. The above information is meant
to provide an abstract view of the current TCAM utilization

Получается, что действительно под мак-таблицу отведено память размером в 3200 едениц.

А теперь то, что заводит меня в стопор:

Занято (746):

C3750G#show mac address-table 
..........
  10    000c.2902.5919    DYNAMIC     Gi1/0/2
  10    000c.2918.451a    DYNAMIC     Gi1/0/2
..........
Total Mac Addresses for this criterion: 746

Свободно (1424):

C3750G#show mac address-table count 
..........
Mac Entries for Vlan 10:
---------------------------
Dynamic Address Count  : 18
Static  Address Count  : 0
Total Mac Addresses    : 18
..........
Total Mac Address Space Available: 1424

Из этих двух выводов получается, что весь обьем мак-таблицы составляет: 746+1424=2170

Почему тогда значение 2170 не соответствует 3200, которое выделено в TCAM-памяти??

Помогите пожалуйста прояснить ситуацию. Заранее спасибо!

 

 

Share this post


Link to post
Share on other sites

ну в старых версиях софта Total Mac Address Space Available вобще 0 показывало ;)

Share this post


Link to post
Share on other sites

вот прикол с размером этой самой таблицы покоя не даёт: по паспорту типа 12 к маков по факту после гоняния тестами по заполнению таблицы с помощью scapy оно на 4 к маках легло

 

c3750#sh mac address-table count
[skiped]
Total Mac Address Space Available: 0

 

ну и в нормальном рабочем состоянии

 

c3750#sh mac address-table count
[skiped]
Total Mac Address Space Available: 3434

 

что наводит на мысли... особенно после

 

c3750#clear mac address-table dynamic
c3750#sh mac address-table count
[skiped]
Total Mac Address Space Available: 4201

Share this post


Link to post
Share on other sites

А как объяснить вот такое чудо?

 

C3560E#sh mac address-table count | include Space
Total Mac Address Space Available: 2164

C3560E#sh platform tcam utilization

CAM Utilization for ASIC# 0                      Max            Used
                                             Masks/Values    Masks/values

Unicast mac addresses:                       6364/6364       7972/7972
IPv4 IGMP groups + multicast routes:         1120/1120         61/61
IPv4 unicast directly-connected routes:      6144/6144       4132/4132
IPv4 unicast indirectly-connected routes:    2048/2048       1172/1172
IPv4 policy based routing aces:               452/452          12/12
IPv4 qos aces:                                512/512           6/6
IPv4 security aces:                           964/964         164/164

 

Share this post


Link to post
Share on other sites

WTF :-|

Вот вот, я и говорю что как-то всьо странно здесь.

Искал на форуме, нашел похожую проблему:

http://forum.nag.ru/forum/index.php?showto...st&p=460653

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

C3750G#show version 
Cisco IOS Software, C3750 Software (C3750-IPSERVICESK9-M), Version 12.2(46)SE, RELEASE SOFTWARE (fc2)
Copyright (c) 1986-2008 by Cisco Systems, Inc.
Compiled Thu 21-Aug-08 15:43 by nachen
Image text-base: 0x00003000, data-base: 0x01880000

ROM: Bootstrap program is C3750 boot loader
BOOTLDR: C3750 Boot Loader (C3750-HBOOT-M) Version 12.1(14r)EA1a, RELEASE SOFTWARE (fc1)

System image file is "flash:c3750-ipservicesk9-mz.122-46.SE.bin"

P.S. У вас проблемки я вижу покруче наших :)

Share this post


Link to post
Share on other sites

Добрый день! У меня проблема несколько иного характера: имеется стек из 4-х 3750, агрегирующий весь трафик небольшого города.

Установлен следующий sdm template:

stack-3750#show sdm prefer
The current template is "desktop default" template.
The selected template optimizes the resources in
the switch to support this level of features for
8 routed interfaces and 1024 VLANs.

  number of unicast mac addresses:                  6K
  number of IPv4 IGMP groups + multicast routes:    1K
  number of IPv4 unicast routes:                    8K
    number of directly-connected IPv4 hosts:        6K
    number of indirect IPv4 routes:                 2K
  number of IPv4 policy based routing aces:         0
  number of IPv4/MAC qos aces:                      512
  number of IPv4/MAC security aces:                 1K

 

Утром часов в 8 можно наблюдать такую картину:

stack-3750#sh mac-address-table count | incl Space
Total Mac Address Space Available: 399
stack-3750#sh mac-address-table | incl Total
Total Mac Addresses for this criterion: 5598

То есть свободное место для новых маков еще есть....

 

Однако, уже где-то в 9 утра место для маков кончается:

stack-3750#sh mac-address-table count | incl Space
Total Mac Address Space Available: 0
stack-3750#sh mac-address-table | incl Total
Total Mac Addresses for this criterion: 6035
stack-3750#sh platform tcam util

CAM Utilization for ASIC# 0                      Max            Used
                                             Masks/Values    Masks/values

Unicast mac addresses:                        784/6272        765/6068
IPv4 IGMP groups + multicast routes:          144/1152         68/508
IPv4 unicast directly-connected routes:       784/6272        765/6068
IPv4 unicast indirectly-connected routes:     272/2176         24/146
IPv4 policy based routing aces:                 0/0             0/0
IPv4 qos aces:                                512/512           8/8
IPv4 security aces:                          1024/1024         41/41

Note: Allocation of TCAM entries per feature uses
a complex algorithm. The above information is meant
to provide an abstract view of the current TCAM utilization

Это плохо. Хочется изменить ситуацию.

 

Я знаю, что место под маки можно увеличить выбрав другой sdm template, а именно VLAN (целых 12 киломаков!!!). Но в таком режиме свитч не будет маршрутизировать, а маршрутизация там очень нужна...

 

Вопросы:

Можно ли не меняя sdm template увеличить место под маки (6К, предусмотренные шаблоном - это мало!!)?

Можно ли как-то задействовать для увеличения таблицы ресурсы всех включенных в стек свитчей? Ибо есть ощущение, что мозг стека - это лишь один коммутатор, а не коллективный разум всех четырех...

 

Гуру, откликнитесь!!!

Share this post


Link to post
Share on other sites
Можно ли не меняя sdm template увеличить место под маки (6К, предусмотренные шаблоном - это мало!!)?

Можно ли как-то задействовать для увеличения таблицы ресурсы всех включенных в стек свитчей? Ибо есть ощущение, что мозг стека - это лишь один коммутатор, а не коллективный разум всех четырех...

выход только один - отказаться от стека и разделить нагрузку. увы, но в стекируя железки вы не нарашиваете ее мощность, только наращиваете кол-во портов.

 

 

Share this post


Link to post
Share on other sites
Добрый день! У меня проблема несколько иного характера: имеется стек из 4-х 3750, агрегирующий весь трафик небольшого города.

Вы просто выросли незаметно и вам тесно, пришло время расставаться с родными железками ).

Нужно менять на 65/76 кошку, а пока временно разбить стек на два стека и сделать маршрутизацию на каждом и между ними L3 p-t-p стык.

 

Share this post


Link to post
Share on other sites

>Можно ли как-то задействовать для увеличения таблицы ресурсы всех включенных в стек свитчей? Ибо есть ощущение, что мозг стека - это лишь один коммутатор, а не коллективный разум всех четырех...

 

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

У меня тоже был стек из 3750. Уперлись в предел 3к роутов. Поменяли на 65xx.

 

Share this post


Link to post
Share on other sites

И все же, суть вопроса не раскрыта. Какую информацию следует брать во внимание как актуальную?

Может тот остаток памяти в разделе "Unicast mac addresses:" TCAM памяти используется еще для каких то целей ???

Помогите разобраться где зарыта собака. Спасибо!

Share this post


Link to post
Share on other sites

Если нет вланов, уходящих на 2 и более портов, переполнение мак таблицы вроде как ничего страшного не вызывает - пакет будет отсылатся на единственный порт в влане. А вот перебор "IPv4 unicast directly-connected routes" вызовет резкое падение производительности, повышение нагрузки на процессор и ошибку в лог: %PLATFORM_UCAST-6-PREFIX: One or more, more specific prefixes could not be programmed into TCAM and are being covered by a less specific prefix

Обращайте внимание на это в первую очередь, а не на мак-таблицу. Часть вланов можно перебросить транком на другую циску, хотя мак-таблица будет переполнена, хоть тормозов не будет.

Edited by Valaskor

Share this post


Link to post
Share on other sites

Более 6тыс хостов на 3560/3750 вешать нельзя!

Ставьте вторую, либо меняйте на более толстую железку.

Share this post


Link to post
Share on other sites
Более 6тыс хостов на 3560/3750 вешать нельзя!

Ставьте вторую, либо меняйте на более толстую железку.

согласен, уже при 3к хостов на железку, появляется желание или разделить нагрузку или поставить что нибудь более человечное.

 

Share this post


Link to post
Share on other sites

 

Скажите, а сколько у вас routed интерфейсов на этой коробке (SVI+no switchport)? Ходили слухи, что если их > 8, то коробка может не достичь числа MAC, указанного в описании SDM template.

Share this post


Link to post
Share on other sites

Во, ща еще круче разогналось:

#sh platform tcam utilization

CAM Utilization for ASIC# 0                      Max            Used
                                             Masks/Values    Masks/values

Unicast mac addresses:                       6364/6364      12083/12083
IPv4 IGMP groups + multicast routes:         1120/1120         51/51
IPv4 unicast directly-connected routes:      6144/6144       4199/4199
IPv4 unicast indirectly-connected routes:    2048/2048       1136/1136
IPv4 policy based routing aces:               452/452          12/12
IPv4 qos aces:                                512/512           6/6
IPv4 security aces:                           964/964         164/164

#sh mac address-table count | include Space
Total Mac Address Space Available: 1355

 

Есть подозрение, может быть маки лернятся из вланов, которые на нее приходят, но не trunk-allowed? (есть у меня такая ситуация)

Но у меня ситуация явно иная, т.к. mac addresses не равно directly-connected routes, а у вас равно.

Share this post


Link to post
Share on other sites
Скажите, а сколько у вас routed интерфейсов на этой коробке (SVI+no switchport)? Ходили слухи, что если их > 8, то коробка может не достичь числа MAC, указанного в описании SDM template.
Еммм... а действительно... для SDM профиля явно написано:

 The current template is "desktop routing" template.
The selected template optimizes the resources in
the switch to support this level of features for
8 routed interfaces and 1024 VLANs.

а у нас на каталисте сейчас, как я насчитал, 24 SVIs. Может в этом то и проблема?

Но у меня ситуация явно иная, т.к. mac addresses не равно directly-connected routes, а у вас равно.
хмм. У Вас вывод ввобще какой-то странный. Ведь параметры Mask и Values в TCAM памяти взаимозависимы: Values=Mask*8. Тоесть одной маскою можно поматчить 8 values. А у Вас эти значения равны.

Вот несколько документов относительно TCAM:

http://www.ciscopress.com/articles/article...29&seqNum=4

http://www.enterprisenetworkingplanet.com/...cle.php/3527301

Edited by AxelMAN

Share this post


Link to post
Share on other sites

А что показывает?

"show sdm prefer" на 6500 серии?

 

Дошел до 3к абонентов, начинаются лаги на 3750g.

 

Number of unicast mac addresses: 6K

 

Все 6K юникастов уже и заняты. Пока растащу на две циски 3750.

Но нигде не нашел возможности 6500, подскажите у кого есть.

Share this post


Link to post
Share on other sites

А что показывает?

"show sdm prefer" на 6500 серии?

 

Такой команды в 6500 нету.

 

А так зависит от супервизора.

http://shop.nag.ru/uploads/docs/Doc/catalyst6000supervisors.pdf

 

Реально в sup32 можно запихать более 20000 и не волноваться, что не влезет.

Share this post


Link to post
Share on other sites

Info-lan спасибо

 

Часть вланов можно перебросить транком на другую циску, хотя мак-таблица будет переполнена, хоть тормозов не будет.

 

От этого #sh platform tcam utilization

значение Unicast mac addresses уменьшится? У кого то так работает?

 

 

Как на 3750 перебросить транками vlanы и сделать чтобы они друг друга видели. Начал делать сегодня, но не уверен что красиво получилось. Покажите пример если не сложно на примере 2-х виланов и 2-х цисок.

Edited by babay951

Share this post


Link to post
Share on other sites

От этого #sh platform tcam utilization

значение Unicast mac addresses уменьшится? У кого то так работает?

Нет не уменьшится. Но его переполнение менее опасно, чем переполнение IPv4-routes. Кстати, show platform ip unicast failed route могут появлятся задолго до момента переполнения счетчиков в tcam utilization.

 

Как на 3750 перебросить транками vlanы и сделать чтобы они друг друга видели. Начал делать сегодня, но не уверен что красиво получилось. Покажите пример если не сложно на примере 2-х виланов и 2-х цисок.

Что именно не получается сделать?

 

interface GigabitEthernet0/1

switchport trunk encapsulation dot1q

switchport trunk native vlan 10

switchport trunk allowed vlan 4,5,8-10,15

switchport mode trunk

switchport nonegotiate

Edited by Valaskor

Share this post


Link to post
Share on other sites

Немного не в тему, но что сообщает команда:

show platform ip unicast failed arp

Есть косяк, когда клиенты не пингуют шлюз, т.е. эту самую c3750g-24t. Решается чисткой арпов в том пользовательском vlan (в схеме vlan-per-switch)

Edited by passer

Share this post


Link to post
Share on other sites

Немного не в тему, но что сообщает команда:

 

show platform ip unicast failed arp

Total of 67 arp entries waiting on ARP-HRPC ThrottleQ

 

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

ARP throttled IP Address

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

215.18.228.13/32 Table:0

10.10.26.73/32 Table:0

10.10.50.92/32 Table:4

10.10.12.3/32 Table:0

10.10.9.33/32 Table:0

10.10.17.60/32 Table:2

10.10.23.61/32 Table:0

10.10.2.207/32 Table:0

10.10.2.204/32 Table:0

10.10.2.205/32 Table:0

10.10.24.205/32 Table:0

10.10.2.202/32 Table:0

10.10.2.203/32 Table:0

10.10.2.200/32 Table:0

10.10.2.201/32 Table:0

10.10.2.198/32 Table:0

10.10.17.196/32 Table:2

10.10.2.199/32 Table:0

10.10.2.197/32 Table:0

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

ARP throttled IP Address

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

 

ARP throttle Table modified. Try again..

 

Что именно не получается сделать?

Вот это ниже и не получается, что то видимо не додумал с маршрутизацией, причем именно шлюз. Клиентов других виланов видно.

Есть косяк, когда клиенты не пингуют шлюз, т.е. эту самую c3750g-24t. Решается чисткой арпов в том пользовательском vlan (в схеме vlan-per-switch)

 

Сегодня клиентов 500 перекинул на другую циску 3750, unicast после этого на первой циске слегка упал, но сейчас в час пик опять на максимуме. И опять тормоза, но не у всех абонентов. А походу у тех кто выхватил ip последним.

Share this post


Link to post
Share on other sites

Ещё такой вопрос.

sh plat tcam util показывает

sh plat tcam ut

 

CAM Utilization for ASIC# 0 Max Used

Masks/Values Masks/values

 

Unicast mac addresses: 784/6272 759/6000

IPv4 IGMP groups + multicast routes: 152/1216 7/29

IPv4 unicast directly-connected routes: 784/6272 759/6000

IPv4 unicast indirectly-connected routes: 272/2176 121/872

IPv4 policy based routing aces: 0/0 0/0

IPv4 qos aces: 768/768 260/260

IPv4 security aces: 1024/1024 37/37

 

А абонентов всего около 3000. Можно как то посмотреть с какого vlan сыпятся unicast? Вообще на всех свитчах клиентских стоит защита (arp inspection + DHCP snooping), ну от силы у клиентов 5 она выключена.

Edited by babay951

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this