Почему моя таблица Cisco 6509 BGP использует две записи в моем TCAM?


10

У меня есть проблема на моем Cisco 6509, каждая запись в моей таблице BGP занимает две записи в TCAM. Если я показываю переадресацию емкости, я вижу записи MPLS в ресурсах пересылки L3. Но я не использую MPLS на своем шасси!

#show run | i mpls
mls cef maximum-routes mpls 508
no mpls ldp advertise-labels
no mpls ip

И мой L3 Forwading:

L3 Forwarding Resources
             FIB TCAM usage:                     Total        Used       %Used
                  72 bits (IPv4, MPLS, EoM)     1032192      899612         87%
                 144 bits (IP mcast, IPv6)        8192           7          1%

                     detail:      Protocol                    Used       %Used
                                  IPv4                      450051         44%
                                  MPLS                      449560         44%
                                  EoM                            1          1%

                                  IPv6                           1          1%
                                  IPv4 mcast                     3          1%
                                  IPv6 mcast                     3          1%

            Adjacency usage:                     Total        Used       %Used
                                               1048576      448758         43%

Есть идеи? Может ли быть так, что маршруты находятся в VRF?


+1 интересный вопрос. Можете ли вы добавить свою версию IOS для сравнения с ответом Bigmstone?
Jwbensley

Ой, моя версия IOS s72033_rp-ADVENTERPRISEK9_WAN-M - Версия 12.2 (33) SXH3a
Иоганн М.

Ответы:


10

Кажется, что 6500 генерирует метки MPLS для каждого маршрута, если BGP выполняется в VRF. Тот факт, что ваше использование IPv4 и MPLS TCAM практически одинаково, по-видимому, также указывает на это. Можете ли вы попробовать эту команду:

show bgp vpnv4 uni all labels

Кажется, есть скрытая команда, которая заставляет IOS распределять метки по VRF, а не по префиксу.

mpls label mode all-vrfs protocol bgp-vpnv4 per-vrf

Это скрытая команда, поэтому IOS ее не показывает. Также перед запуском можно попробовать запустить:

show ip vrf detail

1
Да, у меня есть одна метка на префикс BGP! #mpls label mode all-vrfs protocol bgp-vpnv4 per-vrf Гул хорошо, но предупреждение. Теперь я вижу "IPv4 VRF Aggr: 16" для всего префикса :) Подождите немного и ... IPv4 449979 44% MPLS 8 1% ХОРОШО! Спасибо :-)
Иоганн М.

7

Ох, 6500. Я управляю небольшой сетью провайдера и запускаю 6500 в качестве PE-маршрутизатора. Худшее решение в моей жизни. (Это было приукрашенное заявление, но вы поняли мою точку зрения.)

Я запускаю полные маршруты BGP в VRF и столкнулся с множеством проблем, связанных с этим.

Твой пример не очень удивителен. Как сказал в своем посте Даниэль, для каждого префикса VRF есть запись LFIB, а также запись VPNv4. Это можно изменить, добавив команду, mpls label mode vrf Internet protocol all-afs per-vrfкак было указано; однако, это не вытащит вас из леса. Если вы изменяете префиксы на VRF, он удаляет запись LFIB (ура!), Но добавляет запись для каждого префикса в таблицу смежности (подождите, что ?!). Так как аппаратная пересылка 6500 является общей для пересылки L2 и L3, это не меняет использование аппаратной памяти вообще. Во всяком случае, это затрудняет поиск проблемы.

Если вы посмотрите на свое использование после того, как вы изменили на использование VRF (используя show platform hardware cef resource-level), это выглядит так, как будто вы устранили проблему. Однако, если вы воспользуетесь командой, show platform hardware cef adjacencies resource-levelто обнаружится, что проблема только что переместилась в другое место.

Ниже приведены результаты одного из моих уровней использования ресурсов 6500 и смежности. Изложение того, о чем я говорю.

Ресурс уровень

Global watermarks: apply to Fib shared area only.
Protocol watermarks: apply to protocols with non-default max-routes

Fib-size: 1024k (1048576), shared-size: 1016k (1040384), shared-usage: 458k(469769)

Global watermarks:
            Red_WM: 95%,   Greem_WM: 80%,   Current usage: 45%

Protocol watermarks:

 Protocol           Red_WM(%)      Green_WM(%)     Current(%)
 --------           ---------      ----------      ----------
 IPV4                --             --              42% (of shared)
 IPV4-MCAST          --             --              0 % (of shared)
 IPV6                --             --              2 % (of shared)
 IPV6-MCAST          --             --              0 % (of shared)
 MPLS                --             --              0 % (of shared)
 EoMPLS              --             --              0 % (of shared)
 VPLS-IPV4-MCAST     --             --              0 % (of shared)
 VPLS-IPV6-MCAST     --             --              0 % (of shared)

Использование смежности

Watermarks apply to regions available for allocation and not pre-reserved
Stats region size for alloc:        444160
Non-stats region size for alloc:    376832

Adjacency Mgr watermarks:

 Type             Red_WM(%)      Green_WM(%)     Current usage(%)
 ----             ---------      ----------      ----------------
 Stats_WM         95%            80%             97%
 Non-Stats_WM     95%            80%             14%

Пост Ивана об этом был основан на моих выводах здесь. В настоящее время я работаю с Cisco, чтобы попытаться решить эту проблему, но, к сожалению, сейчас нет способа исправить это.

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


+1 Отличное дополнение к ответу Дэниела. Я думал о посте Ивана, когда читал ваш ответ, потом увидел, что вы связались с ним :) Вы сказали, что работаете над решением с Cisco, которое, как я полагаю, относится к TAC. Можете ли вы добавить в свой пост свою версию IOS?
Jwbensley

Отличный комментарий! Но, как ни странно show platform hardware cef [...], не существует в моем C6509. Но если я увижу show cef fib, это страшно: Totals : 96942392/97131416 ( 99%) [4296]и ADJ: adjacency : 132616/132792 ( 99%) [4]
Иоганн М.

Я SUP2T. Я предполагаю, что вы SUP720?
bigmstone

@javno, я считаю 15.1 (1) SY. Слишком ленив к VPN с этим дерьмовым беспроводным аэропортом. Я подтвердлю это и отредактирую, если это нужно изменить ... но я почти уверен, что это то, что я бегу. Да, у меня есть дело TAC, которое было открыто в течение ~ 6 месяцев. Работаем с парой инженеров, чтобы понять, как лучше решить эту проблему. Я пытаюсь убедить их использовать метки следующего перехода ... посмотрим.
bigmstone

@bigmstone: Да, я SUP720 (3BXL)
Иоганн М.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.