проблемы с меткой VPNV4-Option-C
-
уже настроено, RP/0/0/CPU0:XR-4#sh run router bgp
Thu Nov 10 20:32:22.445 UTC
router bgp 12345
address-family ipv4 unicast
allocate-label all
!
сосед 11.11.11.11
удаленный-as 12345
источник обновления Loopback0
адресная семья ipv4 маркированный-одноадресный
следующий-прыжок-сам
!
!
сосед 172.168.168.3
удаленный-as 321
адресная семья ipv4 маркированный-одноадресный
маршрутная политика PASS в
маршрутная политика PASS из -
RP/0/0/CPU0:XR-4#sh ip route
Thu Nov 10 20:35:36.081 UTC Коды: C — подключено, S — статическое, R — RIP, B — BGP, (>) — путь
перенаправления D — EIGRP, EX — EIGRP внешнее, O — OSPF, IA — OSPF межзональное
N1 — OSPF NSSA внешнее типа 1, N2 — OSPF NSSA внешнее типа 2
E1 - OSPF внешний тип 1, E2 - OSPF внешний тип 2, E - EGP
i - ISIS, L1 - IS-IS уровень 1, L2 - IS-IS уровень 2
ia - IS-IS межзональный, su - IS-IS сводный null, * - кандидат по умолчанию
U - статический маршрут на пользователя, o - ODR, L - локальный, G - DAGR, l - LISP
A - доступ/абонент, a - маршрут приложения
M - мобильный маршрут, r - RPL, (!) - FRR Резервный путь Шлюз последней инстанции не установлен B 8.8.8.8/32 [20/3] через 172.168.168.3, 03:05:31
O 11.11.11.11/32 [110/3] через 192.168.34.3, 03:08:19, GigabitEthernet0/0/0/0
O 33.33.33.33/32 [110/2] через 192.168.34.3, 03:08:33, GigabitEthernet0/0/0/0
L 44.44.44.44/32 подключено напрямую, 03:08:41, Loopback0
C 172.168.168.0/24 подключен напрямую, 03:08:39, GigabitEthernet0/0/0/1
S 172.168.168.3/32 подключен напрямую, 03:08:39, GigabitEthernet0/0/0/1
L 172.168.168.4/32 подключен напрямую, 03:08:39, GigabitEthernet0/0/0/1
O 192.168.13.0/24 [110/2] через 192.168.34.3, 03:08:33, GigabitEthernet0/0/0/0
O 192.168.23.0/24 [110/2] через 192.168.34.3, 03:08:33, GigabitEthernet0/0/0/0
C 192.168.34.0/24 подключено напрямую, 03:08:39, GigabitEthernet0/0/0/0
L 192.168.34.4/32 подключено напрямую, 03:08:39, GigabitEthernet0/0/0/0
O 192.168.35.0/24 [110/2] через 192.168.34.3, 03:08:33, GigabitEthernet0/0/0/0
RP/0/0/CPU0:XR-4#
RP/0/0/CPU0:XR-4#sh bgp ipv4 labeled-unicast
Thu Nov 10 20:36:26.148 UTC Идентификатор
маршрутизатора BGP 44.44.44.44, локальный номер AS 12345 Интервал общего
сканирования BGP 60 секунд
Непрерывная маршрутизация включена Состояние
таблицы BGP: Активное ID
таблицы: 0xe0000000 Версия RD: 8 Основная таблица
маршрутизации BGP версии 8
BGP NSR Начальная версия initsync 2 (достигнута)
BGP NSR/ISSU Версии Sync-Group 0/0 Интервал
сканирования BGP 60 секунд Коды состояния: s подавлено, d затухание, h история, * действителен, > лучший
i - внутренний, r сбой RIB, S устаревший, N отбрасывание следующего
шага Коды происхождения: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path*8.8.8.8/32 172.168.168.3 3 0 321 i*
i11.11.11.11/32 11.11.11.11 0 100 0 i Обработано 2 префикса, 2 пути
RP/0/0/CPU0:XR-4#sh bgp ipv4 labeled-unicast summ
Thu Nov 10 20:36:31.568 UTC Идентификатор
маршрутизатора BGP 44.44.44.44, локальный номер AS 12345 Интервал общего
сканирования BGP 60 секунд
Непрерывная маршрутизация включена Состояние
таблицы BGP: Активное ID
таблицы: 0xe0000000 Версия RD: 8 Основная таблица
маршрутизации BGP версии 8
BGP NSR Начальная версия initsync 2 (достигнута)
BGP NSR/ISSU Версии Sync-Group 0/0 Интервал
сканирования BGP 60 секунд BGP работает в режиме STANDALONE. Процесс RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer
Speaker 8 8 8 8 8 0 Сосед Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
11.11.11.11 0 12345 135 136 8 0 0 02:10:01 1
172.168.168.3 0 321 181 194 8 0 0 03:09:28 1 RP/0/0/CPU0:XR-4#sh ip route
Thu Nov 10 20:36:45.437 UTC Коды: C — подключено, S — статическое, R — RIP, B — BGP, (>) — путь
перенаправления D — EIGRP, EX — EIGRP внешнее, O — OSPF, IA — OSPF межзональное
N1 — OSPF NSSA внешнее типа 1, N2 — OSPF NSSA внешнее типа 2
E1 - OSPF внешний тип 1, E2 - OSPF внешний тип 2, E - EGP
i - ISIS, L1 - IS-IS уровень 1, L2 - IS-IS уровень 2
ia - IS-IS межзональный, su - IS-IS сводный null, * - кандидат по умолчанию
U - статический маршрут на пользователя, o - ODR, L - локальный, G - DAGR, l - LISP
A - доступ/абонент, a - маршрут приложения
M - мобильный маршрут, r - RPL, (!) - FRR Резервный путь Шлюз последней инстанции не установлен B 8.8.8.8/32 [20/3] через 172.168.168.3, 03:06:40
O 11.11.11.11/32 [110/3] через 192.168.34.3, 03:09:29, GigabitEthernet0/0/0/0
O 33.33.33.33/32 [110/2] через 192.168.34.3, 03:09:42, GigabitEthernet0/0/0/0
L 44.44.44.44/32 подключено напрямую, 03:09:51, Loopback0
C 172.168.168.0/24 подключен напрямую, 03:09:48, GigabitEthernet0/0/0/1
S 172.168.168.3/32 подключен напрямую, 03:09:48, GigabitEthernet0/0/0/1
L 172.168.168.4/32 подключен напрямую, 03:09:48, GigabitEthernet0/0/0/1
O 192.168.13.0/24 [110/2] через 192.168.34.3, 03:09:42, GigabitEthernet0/0/0/0
O 192.168.23.0/24 [110/2] через 192.168.34.3, 03:09:42, GigabitEthernet0/0/0/0
C 192.168.34.0/24 подключен напрямую, 03:09:48, GigabitEthernet0/0/0/0
L 192.168.34.4/32 подключено напрямую, 03:09:48, GigabitEthernet0/0/0/0
O 192.168.35.0/24 [110/2] через 192.168.34.3, 03:09:42, GigabitEthernet0/0/0/0
RP/0/0/CPU0:XR-4#sh mpl ld для
четверга, 10 ноября, 20:36:59.216 UTC Коды
:- = восстановление метки GR, (!) = чистый резервный путь LFA
FRR {} = стек меток с многострочным выводом для маршрута
G = GR, S = устаревший, R = удаленный резервный путь LFA FRR Префикс Метка Метки Исходящий Следующий прыжок Флаги
Вход Выход Интерфейс G S
R--------------- ------- -------------- ------------ ------------------- -----
11.11.11.11/32 434347 44446 Gi0/0/0/0 192.168.34.3
33.33.33.33/32 434343 ImpNull Gi0/0/0/0 192.168.34.3
172.168.168.3/32 434348 Без метки Gi0/0/0/1 point2point
192.168.13.0/24 434344 ImpNull Gi0/0/0/0 192.168.34.3
192.168.23.0/24 434345 ImpNull Gi0/0/0/0 192.168.34.3
192.168.35.0/24 434346 ImpNull Gi0/0/0/0 192.168.34.3 -
Привет,
@feroz syed
, Я быстро пересоздал систему и столкнулся с теми же проблемами, что и ты. По какой-то причине XR-1 не устанавливает метку LDP, полученную в записи CEF. Похоже, решение заключается не в запуске сеанса VPNv4 напрямую между XR-1 и R8, а в использовании одноадресной передачи eBGP VPNv4 между двумя маршрутными рефлекторами, как описано в следующем документе, что в любом случае более вероятно в производственной сети: https://www.cisco.com/c/en/us/support/docs/multiprotocol-label-switching-mpls/mpls/200523-Configuration-and-Verification-of-Layer.html Таким образом, в вашем сценарии вы можете запустить сеанс eBGP VPNv4 unicast между XR-3 и R7 и отразить эти маршруты на XR1 и R8. У меня это сработало. Попробуйте и дайте мне знать, если у вас возникнут вопросы. С уважением, С уважением,
Гарольд Риттер, CCIE #4168 (EI, SP) -
Здравствуйте, г-н
@Harold Ritter
, спасибо за ответ. Я уже работаю над CML с той же топологией, чтобы проверить, работает ли она. Однако, если это то же самое, я последую вашему совету. Еще раз спасибо за помощь. -
Если не возражаете, не могли бы вы описать, как вы устранили проблему, как вы обнаружили t.
-
Привет,
@feroz syed
, Я был очень удивлен тем, что XR-1 не установил полученную метку LDP. Сначала я подумал, что это может быть ограничением XRv 6.3.1. Вчера вечером у меня возникла идея. Я уже видел похожую ситуацию здесь, в сообществе поддержки Cisco, и вспомнил, что она была связана с командой «ebgp-multihop». Я посмотрел и нашел информацию, которую предоставил. Это действительно редкий случай, так как очень немногие люди будут иметь сессию eBGP VPNv4 multi hop от одного PE в одном AS к PE в другом AS. Наиболее распространенным решением является сессия eBGP VPNv4 между RR в каждом AS. Причина, по которой это работает без «ebgp-multihop mpls», когда сессия eBGP VPNv4 multi hop проходит между RR, заключается в том, что RR является только плоскостью управления и поэтому не возражает против получения обновлений от другого AS через путь без коммутации меток. С другой стороны, если сессия идет от PE к PE, плоскость управления будет работать так же, как и в случае от RR к RR, и маршруты VPNv4 будут получены правильно, но поскольку маршруты получаются через путь без коммутации меток, что является поведением по умолчанию для «ebgp-multihop» в XR, плоскость данных нарушается, поскольку она использует тот же путь без коммутации меток, что и плоскость управления, а это недопустимо для плоскости данных VPNv4. Таким образом, в заключение, «ebgp-multihop mpls» требуется, если как плоскость управления eBGP VPNv4, так и плоскость данных используют один и тот же путь. С уважением, С уважением,
Гарольд Риттер, CCIE #4168 (EI, SP) -
Большое спасибо за вашу помощь и ваше время.
Здравствуйте! Похоже, вам интересна эта беседа, но у вас пока нет учетной записи.
Вы устали просматривать одни и те же посты каждый раз, когда заходите на сайт? После регистрации, вам не придётся искать обсуждения в которых вы принимали участие, настройте уведомления о новых сообщениях так как вам это удобно (по электронной почте или уведомлением). У вас появится возможность сохранять закладки и ставить лайки постам, чтобы выразить свою благодарность другим участникам сообщества.
С вашими комментариями этот пост может стать ещё лучше 💗
Зарегистрироваться Войти