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

cisco 6500 mac address learning неи зучает mac адреса

наступил на нечто сттанное. на 65 циске сликшлм мало маков по сравнению с реальностью.

Есть учавсток сети, схаматично выглядит так

 

[bras] -> [cisco6500 L2] -- access switches

 

Пользователм подключаюся к брасу по PPPoE.

Активных сессий порядка 1000.

 

на днях воткнулся в 1 из портов ноутом и запустил tcpdump -nni

и увидел что трафик от браса летит во все порты, где есть соответствующие влан (вланы).

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

Что ещё смущает - сессий вотпрям сейчас 700, но при этом

 

#sh mac address-table count

MAC Entries for all vlans :

Dynamic Address Count: 153

Static Address (User-defined) Count: 15

Total MAC Addresses In Use: 168

Total MAC Addresses Available: 65536

 

и в этот же момент

 

ASW1_C6509#show mac address-table count module 1

MAC Entries for module 1 [FE 1] :

Dynamic Address Count: 988

Static Address (User-defined) Count: 15

Total MAC Addresses In Use: 1003

Total MAC Addresses Available: 65536

MAC Entries for module 1 [FE 2] :

Dynamic Address Count: 678

Static Address (User-defined) Count: 15

Total MAC Addresses In Use: 693

Total MAC Addresses Available: 65536

 

Cisco IOS Software, s72033_rp Software (s72033_rp-ADVENTERPRISEK9-M), Version 12.2(33)SXH8, RELEASE SOFTWARE (fc1)

Technical Support: http://www.cisco.com/techsupport

Copyright © 1986-2010 by Cisco Systems, Inc.

Compiled Tue 28-Sep-10 23:28 by prod_rel_team

 

ROM: System Bootstrap, Version 12.2(17r)SX5, RELEASE SOFTWARE (fc1)

 

 

Как такое может бытьи как бороться?

Share this post


Link to post
Share on other sites

Так.. по счётчикам в mac address-table count и show mac address-table count module 1 вопрос снимается.. это проделки dfc

 

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

Share this post


Link to post
Share on other sites

весь абонентский трафик разлетается по всем портам?

ну во первых что стоит на доступе? скорее всего коллизии хешей именно там - за циско такого не замечено.

насколько велик широковещательный домен вланов? что на доступе настроено?

Share this post


Link to post
Share on other sites

sup какой?

ну и, разумеется, dst-mac отсутствует у вас в fdb ?

 

у нас такая-же проблема, но у нас маков 50к. Когда мы обнаружили вот этот документ то сильно удивились. Там сказано, что эффективность таблицы у PFC3 - 50%. То есть при таблице в 65к в неё гарантированно влезет 32к.

 

Всё это наводит на мысли о том, что коллизии возможны при любом заполнении fdb.

 

Ещё есть вот такой интересный документ в нём показано как посмотреть статистику по этим самым коллизиям:

remote command module 5 show platform hardware earl statistic

 

Как временное решение, чтобы трафик не валил на соседние брасы, на портах с брасами мы прописали маки самих брасов, и сделали

switchport block unicast

.

А в направлении абонентов дальше стоят X670, которые уже имеют бОльшую fdb, и корректно всё распихивают по нужным портам.

Share this post


Link to post
Share on other sites

весь абонентский трафик разлетается по всем портам?

ну во первых что стоит на доступе? скорее всего коллизии хешей именно там - за циско такого не замечено.

насколько велик широковещательный домен вланов? что на доступе настроено?

 

На сколько я увидел да, где есть тот же vlan

 

на дотупах как правило DES-3200-52 (С1 4.39.B008)

реже DES-3052 (A1 2.94.B08)

 

и есть ещё несколько выносов в виде (рисую опять от 65)

 

[Cisco6500] - > [ zuxel XGS-4728F V4.00(BBC.0) ] - DES-3200-52 / DES-3052

Сильно смущает то, что трафик не от абонентов к брасу,а именно от браса к абонентам летит во все поры с соответствующим vlan

 

Больше всего заметил на том влане, который не сегментирован..

Share this post


Link to post
Share on other sites

sup какой?

ну и, разумеется, dst-mac отсутствует у вас в fdb ?

 

у нас такая-же проблема, но у нас маков 50к. Когда мы обнаружили вот этот документ то сильно удивились. Там сказано, что эффективность таблицы у PFC3 - 50%. То есть при таблице в 65к в неё гарантированно влезет 32к.

 

Всё это наводит на мысли о том, что коллизии возможны при любом заполнении fdb.

 

Ещё есть вот такой интересный документ в нём показано как посмотреть статистику по этим самым коллизиям:

remote command module 5 show platform hardware earl statistic

 

Как временное решение, чтобы трафик не валил на соседние брасы, на портах с брасами мы прописали маки самих брасов, и сделали

switchport block unicast

.

А в направлении абонентов дальше стоят X670, которые уже имеют бОльшую fdb, и корректно всё распихивают по нужным портам.

 

 

Sup-ы стоят WS-SUP720-3B + WS-F6700-DFC3B

 

Самое интересное что если на циске сказать sh mac-address-table address мак_на_который_флудим то он есть за тем портом который сомтрит в сторону дома абонента/выноса

И при этом трафик на этот мак вижу на всех портах с соответствующим маком. Пока заметил на паре районов, которые ещё не сегментированы (так сетка досталась в наследство..)

Сегодня ещё пролверю что на портах с теми районами, которые уже "сегментировал" по влану на дом.

 

Изначально меня смутило что в m sh mac-address-table маков было мало.

потом посмотрел на show mac address-table count module 1

 

тут количство маков ~ равно количеству абонентов.

Сейчас вот ещё включил

mac-address-table synchronize

 

сейчас и sh mac-addrss-table похож на правду

#sh mac address-table count

MAC Entries for all vlans :

Dynamic Address Count: 1288

Static Address (User-defined) Count: 19

Total MAC Addresses In Use: 1307

Total MAC Addresses Available: 65536

 

g3fox

remote command module 1 show platform hardware earl statistic

 

 

Superman 0 Forwarding statistics:

 

Forwarded Frames = 0x00000002154EB882 (8947415170)

Frames fwd'ed to Tycho = 0x0000000164F93BE2 (5989022690)

L3 results rcvd = 0x0000000164F93BE2 (5989022690)

Src Mac entries created in Bank 0 = 0x00000001596CBE7E (5795266174)

Src Mac entries created in Bank 1 = 0x00000000BBE1FA05 (3152148997)

Dst Mac entries created in Bank 0 = 0x000000015AB20B3F (5816585023)

Dst Mac entries created in Bank 1 = 0x00000000BA9CAD44 (3130830148)

L2 banks congest status = 0x0000000000000000 (0)

frames redirected due to Src Mac = 0x0000000000000000 (0)

frames redirected due to Dst Mac = 0x00000000000491D0 (299472)

Src Mac misses = 0x00000000002383C2 (2327490)

Dst Mac misses = 0x0000000000CC3423 (13382691)

line full encountered during New l = 0x0000000000000000 (0)

frames matching fid_hit reg = 0x000000000020D4B3 (2151603)

frames rcvd with protocol code 0 = 0x000000007312B1C9 (1930605001)

frames rcvd with protocol code 1 = 0x0000000000001390 (5008)

frames rcvd with protocol code 2 = 0x0000000000000000 (0)

frames rcvd with protocol code 3 = 0x000000000000021D (541)

frames rcvd with protocol code 4 = 0x0000000000000000 (0)

frames rcvd with protocol code 5 = 0x0000000000000000 (0)

frames rcvd with protocol code 6 = 0x00000000001991DF (1675743)

frames rcvd with protocol code 7 = 0x0000000000000000 (0)

frames rcvd with protocol code 8 = 0x0000000000000000 (0)

frames rcvd with protocol code 9 = 0x0000000000000000 (0)

frames rcvd with protocol code 10 = 0x0000000000000000 (0)

frames rcvd with protocol code 11 = 0x0000000000000000 (0)

frames rcvd with protocol code 12 = 0x0000000000000000 (0)

frames rcvd with protocol code 13 = 0x0000000000000000 (0)

frames rcvd with protocol code 14 = 0x0000000000000000 (0)

frames rcvd with protocol code 15 = 0x00000001A2225F2F (7015128879)

bytes rcvd with protocol code 0 = 0x000001628DC644F4 (1522797004020)

bytes rcvd with protocol code 1 = 0x00000000000779AA (489898)

bytes rcvd with protocol code 2 = 0x0000000000000000 (0)

bytes rcvd with protocol code 3 = 0x000000000000AB2D (43821)

bytes rcvd with protocol code 4 = 0x0000000000000000 (0)

bytes rcvd with protocol code 5 = 0x0000000000000000 (0)

bytes rcvd with protocol code 6 = 0x000000001CD63866 (483801190)

bytes rcvd with protocol code 7 = 0x0000000000000000 (0)

bytes rcvd with protocol code 8 = 0x0000000000000000 (0)

bytes rcvd with protocol code 9 = 0x0000000000000000 (0)

bytes rcvd with protocol code 10 = 0x0000000000000000 (0)

bytes rcvd with protocol code 11 = 0x0000000000000000 (0)

bytes rcvd with protocol code 12 = 0x0000000000000000 (0)

bytes rcvd with protocol code 13 = 0x0000000000000000 (0)

bytes rcvd with protocol code 14 = 0x0000000000000000 (0)

bytes rcvd with protocol code 15 = 0x00000478647574EB (4915128005867)

frames rate limited = 0x0000000000000000 (0)

correctable errors in bank 0 = 0x0000000000000000 (0)

uncorrectable errors in bank 0 = 0x0000000000000000 (0)

correctable errors in bank 1 = 0x0000000000000000 (0)

uncorrectable errors in bank 1 = 0x0000000000000000 (0)

DBus Header Checksum errors = 0x0000000000000000 (0)

address of the line full = 0x00000A89

address of the last error in Bank0 = 0x00004000

address of the last error in Bank1 = 0x00003100

 

Superman 1 Forwarding statistics:

 

Forwarded Frames = 0x00000001A1897390 (7005107088)

Frames fwd'ed to Tycho = 0x00000001A08F3AA4 (6988708516)

L3 results rcvd = 0x00000001A08F3AA4 (6988708516)

Src Mac entries created in Bank 0 = 0x0000000160CF0A74 (5919148660)

Src Mac entries created in Bank 1 = 0x0000000040BA691C (1085958428)

Dst Mac entries created in Bank 0 = 0x00000000D558AF32 (3579359026)

Dst Mac entries created in Bank 1 = 0x00000000CC30C45E (3425748062)

L2 banks congest status = 0x0000000000000000 (0)

frames redirected due to Src Mac = 0x0000000000000000 (0)

frames redirected due to Dst Mac = 0x000000000000A767 (42855)

Src Mac misses = 0x0000000000294AC7 (2706119)

Dst Mac misses = 0x00000000B012C17D (2954019197)

line full encountered during New l = 0x0000000000000000 (0)

frames matching fid_hit reg = 0x000000000020D559 (2151769)

frames rcvd with protocol code 0 = 0x0000000008BF52DA (146756314)

frames rcvd with protocol code 1 = 0x0000000000001970 (6512)

frames rcvd with protocol code 2 = 0x0000000000000000 (0)

frames rcvd with protocol code 3 = 0x0000000000000459 (1113)

frames rcvd with protocol code 4 = 0x0000000000000000 (0)

frames rcvd with protocol code 5 = 0x0000000000000000 (0)

frames rcvd with protocol code 6 = 0x00000000001458E2 (1333474)

frames rcvd with protocol code 7 = 0x0000000000000000 (0)

frames rcvd with protocol code 8 = 0x0000000000000000 (0)

frames rcvd with protocol code 9 = 0x0000000000000000 (0)

frames rcvd with protocol code 10 = 0x0000000000000000 (0)

frames rcvd with protocol code 11 = 0x0000000000000000 (0)

frames rcvd with protocol code 12 = 0x0000000000000000 (0)

frames rcvd with protocol code 13 = 0x0000000000000000 (0)

frames rcvd with protocol code 14 = 0x0000000000000000 (0)

frames rcvd with protocol code 15 = 0x0000000198BC8565 (6857459045)

bytes rcvd with protocol code 0 = 0x000000093157DE60 (39482547808)

bytes rcvd with protocol code 1 = 0x000000000009B3D4 (635860)

bytes rcvd with protocol code 2 = 0x0000000000000000 (0)

bytes rcvd with protocol code 3 = 0x0000000000016029 (90153)

bytes rcvd with protocol code 4 = 0x0000000000000000 (0)

bytes rcvd with protocol code 5 = 0x0000000000000000 (0)

bytes rcvd with protocol code 6 = 0x000000000C0E2C53 (202255443)

bytes rcvd with protocol code 7 = 0x0000000000000000 (0)

bytes rcvd with protocol code 8 = 0x0000000000000000 (0)

bytes rcvd with protocol code 9 = 0x0000000000000000 (0)

bytes rcvd with protocol code 10 = 0x0000000000000000 (0)

bytes rcvd with protocol code 11 = 0x0000000000000000 (0)

bytes rcvd with protocol code 12 = 0x0000000000000000 (0)

bytes rcvd with protocol code 13 = 0x0000000000000000 (0)

bytes rcvd with protocol code 14 = 0x0000000000000000 (0)

bytes rcvd with protocol code 15 = 0x0000069DE3EF5CC9 (7275203747017)

frames rate limited = 0x0000000000000000 (0)

correctable errors in bank 0 = 0x0000000000000000 (0)

uncorrectable errors in bank 0 = 0x0000000000000000 (0)

correctable errors in bank 1 = 0x0000000000000000 (0)

uncorrectable errors in bank 1 = 0x0000000000000000 (0)

DBus Header Checksum errors = 0x0000000000000000 (0)

address of the line full = 0x00000601

address of the last error in Bank0 = 0x00001040

address of the last error in Bank1 = 0x00008000

Share this post


Link to post
Share on other sites

В общем после включения mac-address-table synchronize проблема решилась...

А теперь вопрос - почему без такая ситуация?

Share this post


Link to post
Share on other sites

Есть у кого мысли касательно такого поведения?

Share this post


Link to post
Share on other sites

Да она самая. В данном случае всё в 1 линейке брасы в 47-48 портах

а по тв сторону которого много флуда во всех портах, где есть тот же vlan - gi 1/15

Share this post


Link to post
Share on other sites

а коммутаторы доступа у вас в каких портах?

или у вас вообще всё в первом модуле?

Share this post


Link to post
Share on other sites

Всё в 1 модуле в портах с 1 по 36. брасы этой же линейке 47/48 порты

Share this post


Link to post
Share on other sites

Странно. Во всяких заумных документах, вроде, упоминается включение синхронизации на DFC только если трафик бегает через разные модули и иногда модули флудят.

А если сделать

show mac-addr addr  ... all

для флудящего мака, то что показывает?

А, кстати, что у вас за модуль то в первом слоте? Покажите

sh module 1

.

У меня нет ни одной DFC карты... Но если сделать

remote command module 1 show platform hardware earl statistic

на супервизоре, то я получаю только одну комбинацию "Superman 0 Forwarding statistics:". А у вас есть ещё и "Superman 1 Forwarding statistics:".

Может быть между ними тоже должна выполняться синхронизация?

 

Вру. Нашёл у себя один dCEF модуль. У него тоже всего одно упоминание "Superman 0 Forwarding statistics:".

Но это всё таки ASIC. А за FDB отвечает PFC ведь?

Edited by g3fox

Share this post


Link to post
Share on other sites

За FDB отвечает DFC на плате, там свой CPU, который программирует TCAM на плате. PFC делает все тоже самое, только глобально для Супервайзора и плат с CFC. Для этого же и синхронизация между разными FDB, кмк.

Во втором документе, что вы скидывали это описано:

 

Verify L2 Forwarding Engines Counters

 

То есть два L2 FE, два Superman, два Fabric ASIC.

 

На Супервайзоре один Superman видимо потому что всего одно включение в фабрику (совпадение? не думаю).

Share this post


Link to post
Share on other sites

Совет дали верный, надо проверить для начала присутствует ли проблемный MAC во всех FDB, если нет, то возможен flooding (насколько я понимаю, если путь трафика лежит между разными картами, или между разными FE в рамках одной карты (в этом я сомневаюсь)):

 

Check MAC addresses are present in all Forwarding Engines in the system (PFC/DFC)... if not, possibly flooding !!
Edited by tehmeh

Share this post


Link to post
Share on other sites

Странно. Во всяких заумных документах, вроде, упоминается включение синхронизации на DFC только если трафик бегает через разные модули и иногда модули флудят.

А если сделать

show mac-addr addr  ... all

для флудящего мака, то что показывает?

 

Вот к примеру 1 из маков который не проблемный

 

sh mac address-table address f81a.6754.8d4f all
Legend: * - primary entry
       age - seconds since last seen
       n/a - not available

 vlan   mac address     type    learn     age              ports
------+----------------+--------+-----+----------+--------------------------
Module 1[FE 1]:
*   14  f81a.6754.8d4f   dynamic  Yes          0   Gi1/15
Module 1[FE 2]:
*   14  f81a.6754.8d4f   dynamic  Yes        190   Gi1/15
Module 2[FE 1]:
   14  f81a.6754.8d4f   dynamic  Yes         40   Gi1/15
Module 2[FE 2]:
   14  f81a.6754.8d4f   dynamic  Yes         40   Gi1/15
Module 3[FE 1]:
   14  f81a.6754.8d4f   dynamic  Yes         40   Gi1/15
Module 3[FE 2]:
   14  f81a.6754.8d4f   dynamic  Yes         40   Gi1/15
Active Supervisor:
   14  f81a.6754.8d4f   dynamic  Yes        125   Gi1/15
Standby Supervisor:
   14  f81a.6754.8d4f   dynamic  Yes        185   Gi1/15

 

Отключил синхронизацию маклов и вижу мак лишь вот так (мак на который идёт флуд)

 

ASW1_C6509#sh mac address-table address  6470.02a1.cdb2 all
Legend: * - primary entry
       age - seconds since last seen
       n/a - not available

 vlan   mac address     type    learn     age              ports
------+----------------+--------+-----+----------+--------------------------
Module 1[FE 1]:
*   14  6470.02a1.cdb2   dynamic  Yes          0   Gi1/15

 

А, кстати, что у вас за модуль то в первом слоте? Покажите

sh module 1

.

У меня нет ни одной DFC карты... Но если сделать

remote command module 1 show platform hardware earl statistic

на супервизоре, то я получаю только одну комбинацию "Superman 0 Forwarding statistics:". А у вас есть ещё и "Superman 1 Forwarding statistics:".

Может быть между ними тоже должна выполняться синхронизация?

 

Вру. Нашёл у себя один dCEF модуль. У него тоже всего одно упоминание "Superman 0 Forwarding statistics:".

Но это всё таки ASIC. А за FDB отвечает PFC ведь?

 

sh module 1          
Mod Ports Card Type                              Model              Serial No.
--- ----- -------------------------------------- ------------------ -----------
 1   48  CEF720 48 port 1000mb SFP              WS-X6748-SFP       SAL09316FY8

Mod MAC addresses                       Hw    Fw           Sw           Status
--- ---------------------------------- ------ ------------ ------------ -------
 1  0014.f289.7070 to 0014.f289.709f   1.4   12.2(14r)S5  12.2(33)SXH8 Ok

Mod  Sub-Module                  Model              Serial       Hw     Status 
---- --------------------------- ------------------ ----------- ------- -------
 1  Distributed Forwarding Card WS-F6700-DFC3B     SAL1026SQFA  4.2    Ok

Mod  Online Diag Status 
---- -------------------
 1  Pass

 

Как я понял на моей линейке 2 "половинки" и линк между ними идёт через SUP

 

Совет дали верный, надо проверить для начала присутствует ли проблемный MAC во всех FDB, если нет, то возможен flooding (насколько я понимаю, если путь трафика лежит между разными картами, или между разными FE в рамках одной карты (в этом я сомневаюсь)):

 

Check MAC addresses are present in all Forwarding Engines in the system (PFC/DFC)... if not, possibly flooding !!

 

Проверил - мак светится всег ов 1 табличке на 1 порту.

Share this post


Link to post
Share on other sites

Судя по тому, что вы предоставили, синхронизация (если отключена) не происходит даже между разными FE в пределах одного модуля.

Прикольно, нужно запомнить.

Share this post


Link to post
Share on other sites

Мда. Надо провести аудит своих 65/76.

Share this post


Link to post
Share on other sites

После праздников попробую заменить DFC в этой линейке... вдруг с dfc трабла

Share this post


Link to post
Share on other sites
Как я понял на моей линейке 2 "половинки" и линк между ними идёт через SUP

Не совсем понятно, что вы имеете ввиду.

 

Local forwarding для плат с DFC в общем случае не должен уходить на SUP, именно для этого DFC и придумали.

Как трафик ходит между портами сильно зависит от архитектуры самой карты.

 

Проблема в том, что, очень грубо говоря, за разные порты отвечает свой Forwarding Engine в рамках одного DFC, и, как оказалось, некоторые MAC были в FDB для одного FE, но не были в другом. Для второго FE и возникал DLF, синхронизация это полечила, не факт, что замена DFC на плате что-то изменит.

Share this post


Link to post
Share on other sites

Я имею ввиду что насамой линейке (не dfc)

2 набора портов,не зависящих друг от друга

Share this post


Link to post
Share on other sites

Хернёй не страдайте. Включите синхронизацию и успокойтесь.

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